組織は大量のドキュメントコレクション（サポートチケット、法的書類、ニュースフィード、研究論文など）を蓄積しており、適切な質問をする前にその内容を理解する必要があります。ラベルやトレーニングデータがなければ、何千もの文書を手動で確認するのは非現実的です。何を検索すればいいかわからない場合、従来の検索は役に立ちません。

この投稿では、この検索の問題に対処するElasticsearchネイティブのアプローチによる教師なし文書クラスタリングと時間軸に沿ったストーリー追跡について説明します。最終的には、次のようにストーリーの文脈を日々にわたってたどることができるようになります。

読み取れる内容：

• なぜクラスタリング埋め込み（検索埋め込みではない）が、クエリーなしでトピック発見を行いたい場合に重要なのか。
• Elasticsearchのk-nearest-neighbor（kNN）とバッチ処理msearch を使用したトピックにより、密度探査型重心分類で文書をグループ化する方法。
• significant_text がクラスターに自動ラベルを付けることで、モデルをトレーニングしなくてもテーマを読めるようにする方法。
• テーマが日々どのように変化するかを示す上で、時間軸に沿ったストーリーチェーンが日々のクラスターをどのように結び付けるのか。

このパイプラインでは、2025年2月のBBCニュースとガーディアンの記事を約8,500件、テストコーパスとして使用しています。ニュースは明確な時間的推移を示すため便利ですが、このパターンは文書の発見が重要なあらゆる場面に適用されます：法的レビュー、コンプライアンスの監視、研究の統合、カスタマーサポートのトリアージ。

スタック：

• Jina v5のクラスタリング埋め込み：トピックグループ化のためのタスク固有の低ランク適応（LoRA）アダプター。JinaはElasticに統合され、そのモデルはElastic Inference Service（EIS）を通じてネイティブで利用可能です。
• Elasticsearch：拡張性のあるkNN、significant_textラベリング、ベクトルストレージ。
• DiskBBQ：ディスクベースのベクトルインデックス形式で、 Better Binary Quantization（BBQ）と階層的なk-平均法による分割を組み合わせ、近似最近近接傍（ANN）加速を実現します。このインデックス分割はベクトル探索の内部で行われ、本投稿で用いる密度探査型クラスタリング・アルゴリズムとは別です。bbq_diskはディスクに量子化されたベクトルを格納し、ヒープにはパーティションメタデータのみを保持することで、bbq_hnswと比較してリソース要件を大幅に削減しながら、高い再現率を維持します。
• グローバルクラスタリング + 日々の時間軸に沿ったリンク付け：発見とストーリーの進化。

以下が必要です：

• Elasticsearchの導入（Elastic Cloud、Elasticsearchサーバーレス、またはElastic Self-Managed 8.18+/9.0+）：bbq_disk 8.18以降が必要です。オプションのdiversify retrieverセクションは9.3+またはサーバーレスが必要です。
• Jina APIキー：無料プランには1000万トークンが含まれており、これはコアクラスタリング・パイプライン（約425万トークン）をカバーします。オプションの検索対クラスタリング比較は、2番目の埋め込みパスを使用します。
• Guardian APIキー（無料）。

セットアップ

必要なパッケージをインストールしてください：

pip install elasticsearch pandas numpy plotly umap-learn python-dotenv pydantic-settings datasets requests

オプション（このリポジトリからスクレイピングヘルパーを実行する場合のみ）：

pip install beautifulsoup4

次に、プロジェクトのルートにある.envファイルでAPIキーを設定します。

ELASTIC_CLOUD_ID=your-cloud-id        # or ELASTIC_HOST=https://...
ELASTIC_API_KEY=your-api-key
JINA_API_KEY=your-jina-key
GUARDIAN_API_KEY=your-guardian-key

このノートブックは load_dotenv(override=True)を呼び出し、局所的な .env 値が優先されます。

Connected to Elasticsearch

パート1：ディスカバリークラスタリング - なぜ埋め込みをクラスタリングするのか？

ほとんどのベクター検索は、クエリを関連文書に一致させるようにトレーニングされた検索埋め込みを使用します 。これは検索には最適ですが、発見には適していません。まったくクエリーせずにコーパスに存在するトピックを見つけたい場合は、類似した文書をグループ化する埋め込みが必要です。

Jina v5では、タスク固有の低ランク適応（LoRA）アダプタを使用してこの問題を解決します。LoRAは、ほとんどのベースモデルの重みを凍結したまま、ターゲットとなる内部層に小さな低ランクの更新を加えるため、完全な再トレーニングを行うことなく、モデルの挙動が特定のタスクにシフトします。同じベースモデルでも、taskパラメータによって異なる埋め込みが生成されます。

クラスタリング・アダプターは、同じトピックに関する文書を埋め込み空間で近づけ、異なるトピックに関する文書を離すように訓練されています。下のビジュアル比較で、その違いが具体的にわかります。

検索とクラスタリング：視覚的な比較

違いを確認するために、両方のタスクタイプを含むサンプル文書を埋め込んでいます。クラスタリングは元の1024次元の埋め込み空間で実行されます。均一多様体近似と射影（UMAP）は、可視化のためそれらの埋め込みを2Dに投影する目的でのみ使用されます。東映UMAPは局所的な近傍構造を保持するため、クラスターの分離を比較する上で有用です。

以下では、同じ480件の文書のサンプルが両方のタスクタイプに埋め込まれ、UMAPで2Dに投影されています。クラスタリングパネルで、より密集していて、分離された色群を探します。

    Full dataset: 8,495 articles
    Sources: guardian: 5749, bbc: 2746
    Date range: 2025-02-01 to 2025-02-28


    Sample: 480 docs across 8 sections
    section
    Film              60
    World news        60
    Australia news    60
    Opinion           60
    Football          60
    US news           60
    Sport             60
    Business          60


    Clustering embeddings: 480
    Retrieval embeddings:  480


    UMAP projection complete

検索埋め込み（左）はトピックを広く分散させます。クラスタリング埋め込み（右）は、同じドキュメントからより緊密で分離されたグループを生成します。

クラスタリング埋め込みは、より緊密で視覚的に際立ったグループを生み出します。検索用の埋め込みはトピックをより均等に分散させ、（きめの細かい類似性で）検索する上で理想的です。しかし、発見のためには、緊密なトピッククラスターが重要です。

このため、このチュートリアルの残りの部分では task="clustering" が使用されています。

データセットの読み込み

次のコーパスは、2025年2月の2つのニュースソースを組み合わせています。

• RealTimeData/bbc_news_alltime HuggingFaceデータセット経由のBBCニュース。
• Guardian Open Platform API経由のThe Guardian。

複数のソースがあると、クラスタリングがトピックではなくソース固有のスタイルを見つけることを検証するのに役立ちます。

    Total articles:  8,495
    
    Source breakdown:
    source
    guardian    5749
    bbc         2746
    
    Date range: 2025-02-01 → 2025-02-28
    Days covered: 28
    
    Sample article:
      Source:  guardian
      Title:   Carbon monoxide poisoning ruled out in death of Gene Hackman and wife, police sa
      Section: Film
      Text:    Authorities have ruled out that Gene Hackman and his wife, Betsy Arakawa, died from carbon monoxide poisoning earlier this week in their home in Santa Fe, New Mexico. The Santa Fe county sheriff, Adan...

クラスタリングタスクによる埋め込み

Jina v5 APIはすべての文書に対してtask="clustering"で呼び出されます。埋め込みはディスクにキャッシュされるため、その後の実行ではAPIを完全にスキップします。

API呼び出しはシンプルです。taskパラメータが、典型的な埋め込み使用との主な違いです。

payload = {
    "model": "jina-embeddings-v5-text-small",
    "input": texts,
    "task": "clustering",  # ← This selects the clustering LoRA adapter
}

以下のタイミングはキャッシュヒットを反映しています。APIに対する最初の実行は、コーパスサイズによって時間がかかります。

    Embeddings ready: 8,495 vectors of dimension 1024
    Time: 0.6s

単一のElasticsearchインデックスへのインデキシング

発見クラスタリングでは、1か月間を1つのインデックス（docs-clustering-all）にまとめます。日々の分割は、時間軸に沿ったストーリーリンクのために後から行われます。

インデックスマッピングでは、ベクトルフィールドにbbq_diskを使用します。

{
  "embedding": {
    "type": "dense_vector",
    "dims": 1024,
    "index": true,
    "similarity": "cosine",
    "index_options": {
      "type": "bbq_disk"        // hierarchical k-means partitioning for ANN index lookup; separate from this post's clustering algorithm
    }
  }
}

1024次元のfloat32ベクトルは4KBです。bbq_disk は階層的k-means法を使用してベクトルを小さなクラスターに分割し、それらをバイナリ量子化し、再スコアリングのためにフルプレシジョンのベクトルをディスクに格納します。パーティションのメタデータのみがヒープに存在し、そのため大規模なコーパスでもメモリ要件は低く抑えられます。より多くのヒープを許容できるワークロードの場合、bbq_hnsw は、より高いリソースコストでより高速な検索を行うための階層的ナビゲーシブル・スモールワールド（HNSW）グラフを構築します。

dense_vectorフィールドタイプは複数の量子化戦略をサポートしています：bbq_diskとbbq_hnswは、ここで使用されている1024次元ベクトルのような高次元埋め込みに最適です。

    Indexed 8,495 documents into docs-clustering-all
    Time: 57.5s

クラスタリング：密度探査型重心分類

HDBSCANのような従来型のクラスタリングアルゴリズムでは、完全なn×dベクトル行列をメモリに保持し、フルパス更新を繰り返し実行できることを前提としています。8,495件のドキュメントを1024次元で扱う場合、処理可能（最大35MB）ではあるものの、このアプローチは追加のインフラストラクチャーなしでは数百万の文書にスケールすることはできません。

このアルゴリズムは、ボロノイ領域への割り当て割り当てとノイズフロアによるKMeans++法の初期化と概念的には似ていますが、ElasticsearchのkNN検索を計算プリミティブとして使用し、ほぼ全ての作業をサーバー側で行います。

1. 文書の5%を密度プローブとしてサンプリングします（ランダムサンプル、最低50件）。
2. バッチ処理された　msearch　kNNによるプローブ密度。各プローブはkNNクエリを実行し、隣接プローブの平均類似度を記録します。平均類似度が高い＝埋め込み空間の密な領域。msearch は単一のHTTPコールで複数の検索リクエストを送信し、これは重要です。密度プローブは数百のkNNクエリを生成し、それらをバッチ処理することでリクエストごとのオーバーヘッドを回避します。
3. 多様性を考慮した高密度シードの選択：中央値以上の密度を持つ候補は、密度の降順でソートされ、既存のすべてのシードとのコサイン類似度が分離閾値を下回る場合にのみ貪欲に受け入れられます。これがクライアント側での唯一の計算です（8,000件の文書で最大0.01秒）。
4. msearch kNNで全ての書類を重心に照らして分類します。各シードが重心として機能し、kNN検索は類似度しきい値を超える近接文書を取得します。各文書は、最も高いスコアを返した重心に割り当てられます。小さなクラスターはノイズとして処理されます。

Elasticsearchが面倒な処理を担当します：msearchは密度プローブ、msearchは分類、significant_textはラベル付けを担います。このコーパス（8,495件の文書）では、5％の密度プローブサンプルが425件のkNNプローブクエリを開始し、msearchが9つのHTTPコール（バッチサイズ50）にバッチ処理され、プローブごとに1つのリクエストを処理することによるオーバーヘッドを回避します。bbq_diskANNルックアップと組み合わせることで、クラスタリング段階を高速かつスケーラブルに保つことができます。kNNクエリは、クラスタリングパス中の速度のために最小のnum_candidates値を使用します。本番環境の検索クエリでは、レイテンシを犠牲にしてリコールを向上させるために、より高いnum_candidates値を使用する必要があります。

クラスターは各重心の周りの埋め込み空間の密度によって決定される実際的なサイズを持ち、厳格なkの上限によって決定されるものではありません。密なトピック領域はより大きなクラスターを生み出し、ニッチなトピックは小さなクラスターを生み出します。

KMeansやHDBSCANが実用的ではない理由

KMeans法は球状クラスターを想定しており、メモリに完全なn×d行列が必要です。メモリに収まるコーパスの場合、HDBSCANは強力な代替手段です。任意のクラスタ形状に対応でき、密度に関するセマンティクスも十分に理解されています。

密度探査型重心アプローチは、異なるニッチをターゲットとしています。ストレージ、検索、およびクラスタリングを1つのシステムで行いたい場合や、スケールがクライアント側の行列操作を実用的でなくするようなコーパスです。これは、Elasticsearch kNNを計算プリミティブとして使用し、任意のクラスターサイズを処理し、ほぼすべての計算をサーバー側で行います。

    Clustered global index in 31.6s
      Total clusters: 82
      Total noise:    2420 (28.5%)
      Density probes: 425 kNN queries via 9 _msearch HTTP calls

ノイズレートについて理解する

最大28%のノイズ率は設計によるもので、故障モードではありません。設定されたsimilarity_thresholdでどの高密度クラスターにも適合しない文書は、一致率が低いと強制的に判断されるのではなく、割り当てられずに残されます。これは品質ゲートの役割を果たします：意見を記したコラム、短い記事、そして一回限りのストーリーは、一貫したグループを定義する主題の密度が不足しているため、クラスタリングに抵抗する性質があります。

しきい値は調整可能です。similarity_thresholdを下げると、より積極的なクラスタリングが生成されます（より多くの文書が割り当てられますが、クラスターは緩くなります）。一方、これを上げると、クラスターが引き締まり、ノイズの割合が増加します。こうした様々なニュースコンテンツを含むコーパスにおいては、約30％のノイズは妥当な動作基点と言えます。本番環境での導入は、分野固有の品質基準に合わせてしきい値を調整することが推奨されます。

significant_textを使用した自動ラベル付け

各クラスターには人間が読みやすいラベルが必要です。Elasticsearchのsignificant_textアグリゲーションは、フォアグラウンドセット（クラスター）とバックグラウンドセット（完全なコーパス）を比較して、異常に頻繁に現れる用語を見つけます。

内部的には、絶対頻度の変動と相対頻度の変動のバランスを取る統計的ヒューリスティック（デフォルトではJLHスコア）を使用しており、機械学習や大規模言語モデル（LLM）の呼び出しは行っていません。英国の政治に関するクラスターでは、starmer、labour、downingのような用語が浮かび上がる可能性があります。これらの用語は、全体的なニュースコーパスと比較して、そのクラスターで不釣り合いに頻出しているためです。

このグローバルパスでは、ラベルはdocs-clustering-allに対して直接計算されるため、前景と背景の両方が月全体のデータから描画されます。パート2では、ラベル付けに日次インデックスパターン（docs-clustering-*）を使用します。これは、クエリで一致するすべてのインデックスを同時に対象にできるワイルドカードで、significant_textにより広い背景を与えてコントラストを高めます。

最小クエリー形状は次のようになります。

{
  "size": 0,
  "query": { "term": { "cluster_id": "72" } },
  "aggs": {
    "label_terms": {
      "significant_text": {
        "field": "text",
        "size": 5,
        "filter_duplicate_text": true
      }
    }
  }
}

significant_text また、品質ゲートの役割も果たします。有意な用語を生成しないクラスターには、特徴的な語彙がありません。これらはまとまりのないグループであり、誤解を招くようなラベルを付けるのではなく、ノイズとして分解する必要があります。

軽量で決定論的なクリーンアップステップで、ノイズの多いラベルの用語（数値トークン、一般的な単語）を削除し、必要に応じて代表的な見出しに切り替えます。これにより、ラベルをElasticsearchネイティブのまま維持しつつ、可読性を向上させます。

    Sample cluster labels:
      cluster   3  (200 docs)  arsenal | mikel | villa
      cluster   1  (198 docs)  volodymyr | ukrainian | kyiv
      cluster   0  (196 docs)  hostages | hamas | israeli
      cluster   4  (187 docs)  scrum | rugby | borthwick
      cluster  52  (185 docs)  fossil | renewable | renewables
      cluster  10  (156 docs)  labour | gwynne | mps
      cluster  40  (151 docs)  novel | novels | literary
      cluster  11  (149 docs)  mewis | sarina | wiegman
      cluster  44  (143 docs)  flooding | rainfall | rain
      cluster  13  (131 docs)  doge | musk | elon
      cluster  12  (128 docs)  murder | insp | knockholt
      cluster   5  (124 docs)  putin | backstop | starmer


    Reassigned 35 docs from incoherent clusters to noise
    Total docs: 8,495
    Clustered:  6,040 (71.1%)
    Noise:      2,455 (28.9%)

クラスターの可視化

以下の可視化は、グローバルクラスタリングパスが発見した内容を示しています：クラスター化された文書とノイズ文書の日付ごとの内訳、全月のUMAP投影、およびクラスターがソースではなくトピックを反映していることを確認するソースミックスチャート。

2025年2月におけるクラスター化された文書とノイズ文書の日次分布。

UMAPの色のついた島はそれぞれがクラスターを表しています。クラスターは、純粋に類似性を埋め込むことで発見された、同じトピックに関する記事の集合です。灰色のノイズポイントは、いずれのクラスターにもきれいに収まらなかった記事（多くの場合、短い記事、意見記事、または一回限りのストーリー）です。

情報源の内訳図を見ると、各クラスターにはBBCニュースとガーディアンの両方からの記事が含まれていることが確認できます。クラスタリングは、ソースではなくトピックを見つけ出すものであり、まさに教師なし学習から期待される結果です。

Diversify Retrieverによるクラスター幅の調査

通常のkNNは、クラスターの重心（密なコア）に最も類似した文書を返します。しかし、実際のクラスターはサブトピックも対象にします。The Diversify Retrieverは、Maximal Marginal Relevance（MMR） を使用して、重心に関連するだけでなく、互いに異なる文書を抽出します。

鍵となるパラメータは λ（ラムダ）です。

• λ = 1.0 → 純粋な関連性（通常のkNNと同じ）。
• λ = 0.0 → 純粋多様性（最大限に分散された結果）。
• λ = 0.5 → バランスが取れている：トピックに関連しているが、異なる角度をカバーしている。

最小Retrieverリクエストの形状は次のようになります。

{
  "size": 8,
  "retriever": {
    "diversify": {
      "type": "mmr",
      "field": "embedding",
      "lambda": 0.5,
      "query_vector": "",
      "retriever": {
        "knn": {
          "field": "embedding",
          "query_vector": "",
          "k": 50,
          "num_candidates": 100
        }
      }
    }
  }
}

type、field、および query_vector パラメーターは、diversifyレベルで必要です。field はMMRに結果間の類似性に使用する dense_vector フィールドを指示し、query_vector は関連性スコアリングの参照点を提供します。

これにより、単に「その中心は何か？」という問いではなく、「このクラスターは実際に何を対象としているのか？」という問いに答えることができます。

    Exploring cluster 52 (185 docs)
    Label: fossil | renewable | renewables
    Centroid computed (dim=1024)


    ========================================================================
    Plain kNN (closest to centroid)
    ========================================================================
      1. [0.9738] Green campaigners fear ministers are poised to award billions of pounds in fresh subsidies to Drax power station, despite strong concerns...
      2. [0.9710] Thirteen more oil and gas licences could be cancelled as ministers decide new guidance for fossil fuel extraction after a landmark court...
      3. [0.9699] Experts have accused the fossil fuel industry of seeking special treatment after lobbyists argued greenhouse gas emissions from oilfields...
      4. [0.9681] Burning wood is a terrible way of producing electricity . Chopping down trees destroys habitats for wildlife, and growing new trees cannot...
      5. [0.9649] Keir Starmer will do huge damage to the global fight against climate change if he gives in to political pressure and allows the development...
      6. [0.9641] Labour will next week be confronted with stark policy choices that threaten to expose the fault lines between the Treasury and the...
      7. [0.9638] The Drax power station near Selby in north Yorkshire burns imported wood pellets  The government has agreed a new funding arrangement with...
      8. [0.9581] If you care about the world we are handing on to future generations, the news on Thursday morning was dramatic. This January was the...
    
    ========================================================================
    Diversify retriever (MMR, lambda=0.5)
    ========================================================================
      1. [0.9738] Green campaigners fear ministers are poised to award billions of pounds in fresh subsidies to Drax power station, despite strong concerns...
      2. [0.9434] Oil and gas interests have waged a coordinated campaign to kill pro-electrification policies that ban gas connections in new buildings ,...
      3. [0.9303] It was interesting to read that new licences for oil and gas production in the North Sea are being delayed by legal action ( Thirteen more...
      4. [0.9139] The US energy secretary, Chris Wright, has said he “would love to see Australia get in the game of supplying uranium and maybe going down...
      5. [0.9077] Rachel Reeves was facing criticism on Saturday night as it was confirmed that a report she cited as evidence that a third ­runway at...
      6. [0.8996] When Margaret Thatcher opened the Hadley Centre for Climate Change in 1990 journalists suggested she was attempting to appear to be doing...
      7. [0.8993] The vast majority of governments are likely to miss a looming deadline to file vital plans that will determine whether or not the world has...
      8. [0.8987] European imports of seaborne gas shipments fell by a fifth last year to their lowest level since the pandemic, according to a new report,...
    
    Overlap: 1/8 documents appear in both result sets
    
    Avg pairwise similarity (lower = more diverse):
      Plain kNN:          0.9057
      Diversify retriever: 0.6965

プレーンなkNNは、トピックの1つの角度、つまり中心点および互いに最も類似したドキュメントの周りにクラスターを形成します。Diversify Retrieverは、同じクラスターの異なるファセット、つまりサブトピック、異なるソース、多様な視点を提示します。

多様性指標はこれを定量的に裏付けます。Diversify Retrieverの結果では、平均ペアワイズ類似度が低く、これは返された文書がより広範囲をカバーしていることを意味します。

これは以下の用途に役立ちます。

• クラスターが実際に対象としている内容を理解。その中心だけでなく端も含め理解します。
• 要約の生成。多様で代表的な文書は、LLMにより良い材料を提供します。
• 人によるレビューや下流工程でのラベリングのために、代表的な例を発見。
• 品質チェック。多様な結果が一貫性に欠けている場合、クラスターの分割が必要かもしれません。

パート2：時間軸に沿ったストーリーチェーン

日をまたいだデータストーリーの追跡

パート1では、トピック発見のために1か月全体をグローバルにクラスタリングしました。時間軸に沿ったフローでは、同じ密度プローブの重心分類が日次インデックスごとに1日単位で独立して実行され、その後、クラスターが隣接する日々にわたってリンクされます。注意：日々のクラスターはパート1のグローバルクラスターとは独立しており、それぞれの1日はその日のコンテンツに合わせて独自のクラスター割り当てとラベルを生成します。

関連付けの手法：サンプルとクエリ

A日目の各クラスターについて：

1. いくつかの代表的な文書をサンプルとして選択します。
2. kNNをB日目のインデックスに対して実行します。
3. B日目のクラスターごとにヒット数を数えます。
4. ヒット率がしきい値（kNNの割合≥ 0.4）を超える場合は、リンクを記録します。

この処理は高速で（クラスターごとにわずかなドキュメントのみがクエリされ、すべてではありません）、ElasticsearchのネイティブkNNを使用し、外部ツールは必要ありません。

Preparing daily indices for temporal linkage...


Indexed 8,495 docs into 28 daily indices


Temporal links found: 808 in 145.4s

Strongest links:
  2025.02.01 'league | arsenal | premier' -> 2025.02.02 'league | season | striker'  (100%)
  2025.02.03 'league | striker | loan' -> 2025.02.04 'league | striker | season'  (100%)
  2025.02.03 'score | operator | gedling' -> 2025.02.04 'league | striker | season'  (100%)
  2025.02.12 'playoff | leg | bayern' -> 2025.02.13 'league | players | injury'  (100%)
  2025.02.14 'league | injury | football' -> 2025.02.15 'league | premier | football'  (100%)
  2025.02.18 'russia | ukraine | talks' -> 2025.02.19 'saudi | russia | arabia'  (100%)
  2025.02.18 'football | league | bayern' -> 2025.02.19 'league | manchester | players'  (100%)
  2025.02.21 'league | premier | manchester' -> 2025.02.22 'game | players | defeat'  (100%)
  2025.02.21 'rugby | calcutta | brilliant' -> 2025.02.22 'game | players | defeat'  (100%)
  2025.02.26 'metals | kyiv | ukrainian' -> 2025.02.27 'ukraine | russia | talks'  (100%)

kNN分数が100％ということは、ソースクラスターからサンプリングされたすべてのドキュメントが同じターゲットクラスターに到達していることを意味し、これは異なる日付間のリンクが理論上最も強くなります。ほとんどの上のリンクはフットボール関連で、これは理にかなっています。プレミアリーグは毎日報道され、高いトピックの一貫性があります。

The score | operator | gedling → league | striker | season リンクは、ニッチなローカルフットボールクラスター（Gedling はノンリーグクラブです）が翌日に広範なプレミアリーグクラスターに吸収される例であり、これは異なる粒度での日々の再クラスタリングの自然な効果です。

ストーリーチェーンの構築

ストーリーチェーンとは、連日にわたって連続した一連のクラスターです。

個々のペアワイズリンクは、月曜日の「UK politics」クラスターが火曜日のクラスターにリンクしていることを示しています。チェーンはストーリー全体を明らかにします。月曜日に始まり、週を通して展開し、金曜日までに消えていくストーリーです。

チェーンは、kNN分数が0.4以上のリンクから貪欲に構築されます。これは、ソースクラスターからサンプリングされたドキュメントの少なくとも40％が単一のターゲットクラスターに到達したことを意味します。最も古いクラスターから開始し、アルゴリズムは常に最も強い発信リンクを追跡します。

    Strong links (kNN fraction >= 0.4): 244
    Story chains spanning 3+ days: 18
      Chain 1: 'ukrainian | kyiv | eastern' (19 days: Feb 3 → Feb 21)
      Chain 2: 'playing | opposition' (19 days: Feb 10 → Feb 28)
      Chain 3: 'tadhg | maro | cadan' (10 days: Feb 1 → Feb 10)
      Chain 4: 'invade | china | putin' (8 days: Feb 21 → Feb 28)
      Chain 5: 'elected | labour | leader' (7 days: Feb 12 → Feb 18)
      Chain 6: 'film | swift | awards' (6 days: Feb 2 → Feb 7)
      Chain 7: 'amendment | termination | reporting' (6 days: Feb 12 → Feb 17)
      Chain 8: 'officers | scene | police' (5 days: Feb 1 → Feb 5)

最も長いチェーンは、ウクライナとロシアに関する報道を19日間連続で追跡していますが、2025年2月の地政学的な緊張が持続していることを考えると、これは驚くべきことではありません。2番目に長いチェーンは、19日間にわたるプレミアリーグのサッカーを追跡するものです。より短いチェーンは、映画賞シーズン（6日間）、シックス・ネーションズラグビー（10日間）、英国の政治指導者に関する報道（7日間）を追跡しています。それぞれのチェーンは、アルゴリズムが日々のインデックス全体にわたる埋め込み類似性のみから発見したストーリー展開を表しています。

サンキー：ストーリーの流れを可視化する

サンキーダイアグラムは、リンクの幅がつながりの強さを表す流れの可視化です。ここでは、各垂直バンドが1日を表し、各ノードは日々のクラスター（ドキュメント数によってサイズが決まる）であり、各色のパスは時間の経過に沿って1つのストーリーチェーンを追跡します。リンク幅はkNNのオーバーラップ強度をエンコードします。リンクが太いほど、サンプリングされたドキュメントの数がより多くターゲットクラスターに到達したことになります。色はチェーンごとに分かれているので、左から右へ流れる1つのカラーパスで1つのストーリーの進行がわかります。

たとえば、ウクライナとロシアのチェーン（比較的長い経路の一つとして示されている）は、2月初旬から第3週まで途切れることなく続いており、一貫して太い線で結ばれていることから、日々の話題の連続性が強いことがわかります。

2025年2月に流れる時間軸に沿ったストーリーチェーン各色のパスは、複数日にわたって続くストーリーを表し、リンクの幅はkNNの重なりの強さを示します。

このアプローチがもたらすメリット

このウォークスルーでは、Elasticsearch上に構築された完全な教師なしドキュメントクラスタリング・パイプラインについて説明しました。

1. クラスタリング埋め込み：Jina v5のタスク固有のアダプターは、トピックのグループ化に最適化された埋め込みを生成し、単なるクエリと文書のマッチングだけではありません。
2. グローバルな発見クラスタリング：1つのインデックスで1か月間をクラスタリングすることで、日をまたいだトピックの発見を最大化します。
3. 密度プローブによる重心分類：5％をサンプリングし、msearch kNNを介して密度をプローブし、多様な高密度シードを選択し、すべての文書を重心に対して分類します。Elasticsearchは負荷の高い計算を処理します。シード選択のみがクライアント側で実行されます（最大0.01秒）。
4. significant_textラベリング：有意性テストは、MLモデルや手動アノテーションなしで意味のあるクラスタラベルを生成します。有意な項を生み出さないクラスタは非整合となり、ノイズに格下げされます。これは内蔵された品質ゲートです。
5. 時間軸に沿ったストーリーのリンク付け：日次インデックスとサンプルおよびクエリのクロスインデックスkNNは、ストーリーが時間とともにどのように進化するかを追跡します。

重要なポイント

• 埋め込みタスクの種類が重要です。クラスタリング埋め込みは、測定可能かつより緊密な話題のグループを生成します。
• Elasticsearchはストレージ層およびクラスタリングエンジンの両方としてkNN検索を通じて機能します。
• 密度探査型重心分類は、ほぼすべての計算をサーバー側で行い、埋め込み空間の密度によって決定される合理的なサイズのクラスターを生成します。
• significant_text 高速で解釈可能で、自動ラベリングと品質管理の両方に効果的です。

このアプローチは、以下の場合に有用です。

• タイムスタンプ付きのテキストがあり、ラベル付きトレーニングデータを使用せずにトピックを発見したい場合があります。
• ストレージ、ベクトル検索、ラベル付け、および時間軸に沿ったリンク付けのために、1つのスタックが必要な場合があります。

検討すべき拡張機能：

• 複数期間クラスタリング（週間、月間集計）。
• リアルタイムのインジェストと段階的なクラスター割り当て。
• LLM生成のクラスタサマリーは、significant_text項をシードとして用います。
• より大規模なスケールでは、サンプリングされたKMeansの重心が密度ベースのクラスタリングのウォームスタートシードとして機能し、探査フェーズのコストを削減できます。

はじめましょう

タイムスタンプ付きの文書コーパスを差し替えます。日付のあるテキストのコレクションであれば、このパイプラインで利用可能です。完全なノートブックとサポートコードは、付属レポジトリで入手できます。

• Elastic Cloudの無料トライアルを開始：bbq_diskサポート付きのマネージドクラスターを数分でご利用いただけます。
• Elasticsearch Serverlessをお試しください：クラスターの管理は不要で、自動的にスケールし、このウォークスルーのすべてをサポートします。

語彙検索（テキストのマッチング）、セマンティック検索（概念のマッチング）、ハイブリッド検索（語彙シグナルとセマンティックシグナルの組み合わせ）は、単独ではこれらの問題を解決できません。語彙検索は「オレンジ」という単語を含むあらゆるものを返す可能性がある一方で、「オレンジ」のような意図の強いクエリに対する純粋なセマンティック検索は、レモンやグレープフルーツなどの関連項目へと広がる可能性があります。ハイブリッド検索はこれらの語彙シグナルとセマンティックシグナルを組み合わせますが、それでもこのクエリをナビゲーションとして扱うべきか、どの制約を適用すべきか、あるいはどのビジネスポリシーを適用すべきかの判断は行いません。欠けているのは検索技術そのものではなく、これがどのような種類のクエリであるか、そして検索を開始する前にどの制約を適用すべきかを理解するガバナンスレイヤーです。

このブログでは、eコマースの検索ガバナンス、その重要性、そして制御レイヤーが予測可能で正確な検索結果をどのように保証するかについて探ります。

eコマース検索におけるガバナンスの意味

ガバナンスは、この文脈では、ユーザーのクエリと検索エンジンの間に意思決定レイヤーを導入することを意味します。このレイヤーは以下の機能を果たします。

• クエリの意図を分類する：これはナビゲーション（「オレンジ」）か発見（「おじいちゃんへの贈り物」）か？
• ビジネス上の制約を適用する：どのようなカテゴリー境界、資格要件、在庫状況の制約、または販売促進ポリシーが適用されるか？
• 適切な戦略への道筋：語彙検索、セマンティック検索、ハイブリッド検索のどれを使用すべきか？

ガバナンスレイヤーは、各クエリにどの検索アプローチを使用すべきか、どの制約を適用しなければならないか、また検索が始まる前にどのビジネスポリシーを適用すべきかを決定します。ガバナンスとハイブリッド検索は混同すべきではありません。ハイブリッド検索は語彙的シグナルと意味的シグナルを組み合わせた検索戦略の一つであり、ガバナンスは語彙、セマンティック、ハイブリッドのいずれを使用すべきかを決定する上流の意思決定レイヤーです。

現状：アプリケーションレイヤーの「スパゲッティ」型実装

現在、多くの小売業者は、アプリケーションレイヤーに直接ロジックを追加することでこの問題を解決しようとしています。これはしばしばスパゲッティコード（何千行ものハードコーディングされたif-then文、正規表現、複雑な検索テンプレート）を生み出します。

このアプローチは、上記に示したような望ましい検索結果をもたらすことができますが、運用上の大きな摩擦を生じさせます。

• エンジニアリングへの依存：ビジネスユーザーやマーチャンダイザーは、エンジニアリングチケットの提出や数週間に及ぶ長い導入サイクルなしに検索動作を変更することができません。
• 断片化：検索ロジックはアプリケーションコードと検索テンプレートの間に散在し、説明や監査が困難になり、進化させるにはリスクが伴います。

チームがルーティングの必要性を認識したとしても、議論はしばしば間違った点、つまりどの取得方法を選択するかという点に集中してしまいます。

誤った選択：語彙検索、セマンティック検索、ハイブリッド検索のどれかを選ぶこと

検索チームはしばしば、この課題を検索戦略の選択として捉えています。この場合の選択肢は語彙/BM25、セマンティック/ベクトル、ハイブリッドの組み合わせです。その考え方は理解できます（検索方法は確かに重要です）が、実際の導入環境で最も一般的な失敗パターンを見落としています。それは、すべてのクエリに対して単一の検索方法を使用すると、最適とは言えない結果しか得られないということです。

コマース検索は、根本的に異なる意図が混在したものです。

• 決定論的で意図の高いナビゲーション（「オレンジ」、「牛乳」、「ピーナッツなしのチョコレート」、「安いオリーブオイル」）。
• 探求的な発見（「山でのハイキング用のジャケット」、「ロボット工学が好きな12歳の子供へのプレゼント」）。
• 運用上の制約（在庫状況、サイズ、価格、色）。
• マーチャンダイジングおよびキャンペーン（ブースト、非表示、季節限定キャンペーン）。

システムがこれらすべてを同じ検索戦略を通じてルーティングした場合、運用モデルにガバナンスが欠如しているため、予測可能な方法で体系的に誤った結果が返されることが多くなります。チームがこれをガバナンスのギャップと認識していない場合、唯一の手段であるチューニングの強化で対応します。

「関連性のチューニング」が循環的になり得る理由

ルーティングレイヤーがなければ、「関連性」はしばしば終わりのないバックログに変わります。

• なぜこのクエリでは主要製品よりも付属品が上位に表示されるのか？
• なぜこのヘッドクエリは突然関連アイテムを表示し始めたのか？
• 同義語を追加したり、アナライザーを調整したり、ハイブリッドを有効にしたりした後に結果が変わった理由は？
• なぜビジネスチームは単一のクエリを修正するのにエンジニアリングリリースが必要なのでしょうか?

チームは、同義語、ブースト、再ランキング実験、アプリケーションコードにおける例外処理などの追加といったさらなるチューニングで対応します。これはしばらくの間は機能するかもしれませんが、クエリの種類を決定し、取得前に適切な制約を適用するための明示的な決定レイヤーがシステムにまだないため、不安定な動作を引き起こすことがよくあります。

eコマースの意図の構造：ヘッドとテール

このセクションでは、eコマースにおける一般的なナビゲーションおよび探索クエリパターンの実用的な省略形として「ヘッド」と「テール」を使用します。現実世界では、多くのクエリには次の両方の側面が含まれています。

ヘッドクエリ（決定論的意図）

これらは、ユーザーが何を求めているかを正確に把握している、直接的なナビゲーションクエリです。

• 単一アイテムの意図（「オレンジ」、「牛乳」、「パン」）。
• 具体的なブランド名や製品ファミリー名（「iPhone 15 Pro」、「ダイエットコーク」）。
• SKU、モデル番号、サイズ（「ABC123」、「air max 270」）。

これらのクエリに対して、語彙検索はトークンの対応関係（単語のマッチング）を処理できますが、ビジネス側は制約を尊重し、予測可能なランキングを返し、制御可能な結果を得ることも期待しています。マーチャンダイザーは、クエリが正しいカテゴリーの境界内で解決され、適格性を尊重し、特定のビジネス優先事項を明確にすることを確認する必要があります。

意図された解決を強制するためにはガバナンスが必要です。例えば、「オレンジ」は農産物カテゴリーに分類されるべきであり、オレンジジュース、オレンジマーマレード、オレンジソーダに分類されるべきではありません。

テールクエリ（探索的発見）

これらは、購入者が探している情報を含む、詳細で意図が豊富なクエリです。

• 「甘いもの好きなおじいちゃんへのプレゼント」
• 「山でのハイキング用のジャケット」
• 「一日中立っていられる靴」

語彙検索は、このような場合にしばしば困難に直面します。セマンティック検索は、文言が一致しなくてもクエリの概念を製品に結びつけることができる点で優れています。しかし、セマンティック検索だけで十分なことは稀です。実際のクエリでは、どの検索方法を用いるかにかかわらず、制約を適用する必要がある場合が多くなります。

制約条件は検索方法に直交

制約をセマンティック検索に適用することは、ハイブリッド検索を意味するものではなく、これらは直交する概念です。Elasticsearchのフィルターやブーストなどの制約は、語彙、セマンティック、ハイブリッドのいずれの検索にも適用できます。課題は、クエリをどのように解釈すべきか、どの制約を強制すべきか、どの検索戦略を使用すべきかを決定することです。

以下は、検索とハードな制約を組み合わせたクエリの例です。

• オレンジ：「オレンジ」という語句に「果物」や「農産物」などのカテゴリー制約を加えた語彙検索を行い、オレンジマーマレード、オレンジジュース、オレンジソーダを除外。
• ビタミンCが豊富な4ドル未満の果物：栄養に関する意図を理解し、結果を果物カテゴリーと4ドル未満の製品に制限するセマンティック検索。
• 履きやすい仕事向けの靴：コンテキスト上の意図に基づくセマンティック検索と、結果を靴に限定するカテゴリー制約。

これらのクエリは単一の方法では処理できません。

• 純粋な語彙検索では不十分です。なぜなら、「ビタミンCが豊富」や「履きやすい」といったフレーズは、きれいに構造化された属性として存在しない可能性があるからです。これらは、製品の説明、レビュー、または仕様から推測する必要があるかもしれません。
• 純粋なセマンティック検索だけでも十分ではありません。明示的な制約がない場合、「ビタミンCが豊富な果物」のようなクエリは、意図したカテゴリーや価格帯から外れたビタミンサプリメント、フルーツ風味の飲料、ビタミン含有量の多い野菜などにまで広がる可能性があるからです。

ガバナンスレイヤーは、クエリが語彙検索、意味的理解、制約の適用、またはこれらの組み合わせを必要とするかどうかを決定します。このレイヤーがなければ、eコマースチームは以下のような状況に陥る可能性があります。

• 制約過剰：意味的なリクエスト（例：「おじいちゃんへのプレゼント」）に対して語彙検索を使用すること。
• 制約不足：意図の明確なヘッドクエリ（「オレンジ」など）に対してセマンティッククエリを使用すること。

ガバナンスの課題は、各クエリのクラスに対して適切な判断を下せるシステムを構築することです。

ガバナンスがない場合に起こること

最も一般的な失敗パターンは単純明快です。チームがユーザーの生のクエリを受け取り、中間的なガバナンスレイヤーを介さずに、それを単一の検索戦略（語彙、セマンティック、またはハイブリッド）に直接渡してしまうのです。

語彙検索は意図した解決を見逃す

ユーザーが「オレンジ」を検索すると、語彙検索戦略では、そのトークンを含むあらゆるもの（オレンジジュース、オレンジマーマレード、オレンジソーダなど）が返される可能性があります。システムはその用語を正しく照合しましたが、ガバナンスがなければ、意図した買い物のコンテキスト（果物）を解決できない可能性があります。

セマンティック検索は意図された制約を超えて広がる

ユーザーが「オレンジ」を検索すると、セマンティックシステムは、関連する製品コンセプト全体から、概念的に関連するアイテムを検索する可能性があります。システムはより広い領域（果物や農産物）を正しく理解しているかもしれませんが、明確なガバナンスがなければ、ユーザーが意図した制約（特にオレンジ）を超えてしまう可能性があります。

ギャップはガバナンスです

必要なのは、クエリの意図を判断し、検索開始前に適切な制約を適用する上流の決定レイヤーです。これにより、以下のような問題が修正されます。

• ユーザーが実際に求めていたものと類似または関連するアイテムが並べて表示される。
• カテゴリーの境界線が曖昧になる（「飲料」対「農産物」）。
• 季節ごとのブーストやキャンペーンを実施できない。
• 予測不可能で説明のつかない結果。

意図の理解とルーティング：必要な制御プレーン

ガバナンスを擁する検索システムは、検索の前（Elasticsearchでクエリを実行する前）に軽量な制御プレーンを導入します。この制御機能については、このブログシリーズの第3部と第4部で詳しく説明します。ここでは、その機能についてのみ説明し、動作原理については触れません。

コントロールプレーンは、以下のように意図を検出し、ビジネスポリシーを適用し、適切な検索戦略を確保することができます。

1. 意図シグナルを検出

• このクエリの目的はナビゲーションか、発見か？
• これは既知のヘッドクエリ（牛乳、パン、バナナなど）か？
• 既知の製品、ブランド、またはカテゴリー解釈はあるか（「オレンジ」は果物と解釈されるべきなど）？
• クエリはSKUのようなパターンですか？
• その検索クエリは、現在実施中のキャンペーンや季節的なポリシー（例えば、クリスマス期間中に七面鳥関連の検索結果をブーストするなど）の対象となるか？
• クエリは制約（カテゴリー、属性、除外、価格/サイズ/色）を示唆しているか？

2. ガバナンスおよびビジネスポリシーを適用

• まず決定論的制約（カテゴリー/属性/否定/可用性）を強制します。
• 積極的なマーチャンダイジングポリシー（ブースト/非表示/ピン留め/上書き）を適用します。
• 優先順位ルールとの競合を解決します（キャンペーンによる上書きとグローバルポリシーなど）。

3. 適切な検索戦略へルーティング

• ナビゲーションや意図の高いヘッドクエリには語彙的（高速かつ決定論的）な処理。
• 真の発見クエリにはセマンティック検索。
• 語彙と意味のシグナルを組み合わせて、明示的なビジネス制約の下で価値を加えるハイブリッド。

実際には、制御プレーンの出力は単に「ハイブリッドを使用」または「セマンティックを使用」というものではありません。これはガバナンスを備えた検索計画であり、購入者の意図、適用されるべき制約とポリシー、そして実行されるべき検索戦略の解釈です。いくつかの簡単な例を挙げると、これがより具体的に理解できるでしょう。

制御プレーンは、各クエリに対して一貫して、予測可能かつスケールで適切なポリシーと検索戦略を選択します。これにより、意図に沿った制約が最初に適用され、ルーティングの決定が暗黙的ではなく明示的になるため、高度な検索方法が本番環境でより予測可能になります。

他のアプローチとの関連

一部のチームは、製品のセマンティクスをより正確に捉えるために改良された埋め込みモデルを使用しており、これによりセマンティック検索の品質を大幅に向上させることができます。その他には、検索後のエンゲージメントやビジネスシグナルに基づいて結果の順序を最適化するために、ランク学習（LTR）などの再ランキング手法を用いるものもあります。どちらも価値があり、多くの場合、互いに補完し合う関係にあります。より良い埋め込みは類似性マッチングを改善します。再ランク付けは取得した候補の順序を改善します。

ガバナンスは問題の別のレイヤーに対処するものであり、情報取得よりも上流に位置します。どの検索戦略（例えば、語彙、セマンティック、ハイブリッド）を使用するか、どのような決定論的制約が必要か、そしてどのクエリで複数のビジネスポリシーを組み合わせるべきかを決定します。

ガバナンスされたコントロールプレーンが可能にすること

一度ガバナンスレイヤーが設置されると、運用モデルは根本的に変わります。売上に直結するクエリは予測可能になり、ビジネスチームは、エンジニアリングリリースサイクルを待たずに検索動作を更新できます。また、セマンティック検索やハイブリッド検索といった高度な検索手法は、全体的なオン/オフスイッチとしてではなく、ルーティングやガードレールの背後で段階的に導入することができます。

このシリーズの次回の記事では、その運用モデルが実際にどのようなものなのか、そしてなぜそれが基盤となる検索技術と同じくらい重要なのかを探ります。

もしマーチャンダイザーがJiraチケットを開いて、売上に大きく影響するクエリを修正するためのデプロイを待たなければならないとしたら、ボトルネックはエンジンではなく、運用モデルにあります。現代のeコマース検索では、ビジネスの意図を迅速かつ安全に、管理可能で監査可能な検索動作に変換する方法が必要であり、同時に、測定可能な価値を付加する高度な検索機能も引き続き活用する必要があります。

このシリーズの次回作

本シリーズで探求するパターンは、検索の上流で機能します。クエリ生成が始まる前に、ビジネス上の意図を適切なクエリ戦略に変換します。次の投稿では、技術的な問題から運用上の問題へと視点を移します。ビジネスチームがエンジニアリングの介入なしに検索動作を変更できるようになった場合に何が起こるか、そしてガバナンスがそれを安全にする理由について説明します。

ガバナンスを備えたeコマース検索を実践

エンタープライズ向けeコマースサービスにおけるエンジニアリング上のボトルネック、脆弱なアプリケーションレイヤーロジック、予測不可能な検索結果などは、Elastic Servicesが解決に役立つ問題です。本シリーズで解説するガバナンスを備えた制御プレーンアーキテクチャーは、Elastic Services Engineeringによって構築されました。

もし貴社のチームが商品企画に関する要望をコード変更に落とし込むためにエンジニアリングサイクルを費やしていたり、検索関連性に関する未解決の課題が一向に減らないようであれば、Elasticは現在のアーキテクチャーを評価し、ガバナンスを備え、ビジネス部門が編集可能な検索システムへの道筋を構築するお手伝いをいたします。Elastic Servicesにご連絡ください。

議論に参加

検索ガバナンス、検索戦略、またはeコマース検索アーキテクチャについてご質問がありますか？より広範なElasticコミュニティの議論に参加しましょう。

最近、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

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

🚀 Starting ingestion of 500 movies from 500_scifi_movies.jsonl...
Ingesting ░░░░░░░░░░░░░░░░░░░░░░░░ 1/500 (0%) | ok:1 | fail:0 | chunks:1 | eta:19m 33s | current:Capricorn One
Ingesting ░░░░░░░░░░░░░░░░░░░░░░░░ 2/500 (0%) | ok:2 | fail:0 | chunks:2 | eta:10m 32s | current:Doghouse
Ingesting ░░░░░░░░░░░░░░░░░░░░░░░░ 3/500 (1%) | ok:3 | fail:0 | chunks:3 | eta:7m 33s | current:Dinocroc
Ingesting ░░░░░░░░░░░░░░░░░░░░░░░░ 4/500 (1%) | ok:4 | fail:0 | chunks:7 | eta:6m 10s | current:Back to the Future           
Ingesting ░░░░░░░░░░░░░░░░░░░░░░░░ 5/500 (1%) | ok:5 | fail:0 | chunks:9 | eta:5m 14s | current:The Projected Man            
Ingesting ░░░░░░░░░░░░░░░░░░░░░░░░ 6/500 (1%) | ok:6 | fail:0 | chunks:11 | eta:4m 41s | current:I, Robot
...
✅ Ingestion complete in 1m 46s. Success: 500, Failed: 0, Chunks: 693.

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は内部で以下の手順を実行します：

1. ベクトル変換：ユーザーの質問「UFOに関する映画やテレビシリーズを5つ探して」は、OpenAIのopenai/text-embedding-3-smallモデルを使ってベクトル埋め込みに変換されます。
2. ベクトル検索：この埋め込みはその後、Elasticsearchに対してベクトル検索を用いてクエリを実行するために使用されます。
3. 結果の取得：Elasticsearchは、クエリに非常に関連性の高い10本の映画（つまり、ユーザーのクエリベクトルに最も近いベクトルを持つ映画）を返します。
4. 回答生成：取得された映画と元のユーザーの質問は、具体的には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についての詳細は、 こちらのオフィシャルドキュメントをご覧ください。

Elastic WorkflowsはKibana内部に組み込まれた自動化エンジンで、シンプルなYAML構成を使用して多段階プロセスを定義できます。各ワークフローはスケジュールやイベント、またはElastic Agent Builderのツールとしてトリガーでき、各ステップでKibana APIを呼び出し、Elasticsearchをクエリし、データを変換できます。

具体的な例としてダッシュボードのビュー数を使用しますが、同じパターンがKibanaの保存済みオブジェクトAPIを通じて提供されるすべてのメトリックにも当てはまります。

要件

• Elastic Cloudまたはセルフマネージドクラスター（バージョン9.3を実行）
• ワークフローが有効（詳細設定）

何かを作る前に、どんなデータがあるのかを理解しましょう。Kibanaはほとんどの設定やメタデータを専用の内部インデックスに保存済みオブジェクトとして保存しています。Kibanaがこの方法で追跡している項目の一つに、使用量カウンターと呼ばれる、特別な保存オブジェクトタイプを使ったダッシュボードの閲覧数があります。次のように、開発ツールから直接クエリできます。

GET kbn:/api/saved_objects/_find?type=usage-counter&filter=usage-counter.attributes.domainId:"dashboard"%20and%20usage-counter.attributes.counterType:"viewed"&per_page=10000

応答は下記のようになります。

{
  "page": 1,
  "per_page": 10000,
  "total": 1,
  "saved_objects": [
    {
      "type": "usage-counter",
      "id": "dashboard:346f3c64-ebca-484d-9d57-ec600067d596:viewed:server:20260310",
      "attributes": {
        "domainId": "dashboard",
        "counterName": "346f3c64-ebca-484d-9d57-ec600067d596",
        "counterType": "viewed",
        "source": "server",
        "count": 1
      },
      ...
    }
  ]

counterNameフィールドはダッシュボードIDであり、countはそのダッシュボードに対する当日中の累積閲覧数です。Kibanaは、1つのダッシュボードにつき1日に1つのカウンターオブジェクトを作成します。オブジェクトIDに日付サフィックス（...views:server:20260310）が表示されます。ユーザーがダッシュボードを開くにつれて、その数は一日を通して増加していきます。

この日常的なドキュメントモデルをインデックスで複製するのではなく、ワークフローの実行ごとに1つのドキュメントを作成します。各ドキュメントは、キャプチャの瞬間におけるその日のダッシュボードの累積ビュー数を記録します。

ステップ2：宛先インデックスの作成

ダッシュボードビューのスナップショットを格納するためのインデックスが必要です。次のコマンドは明示的なマッピングで作成し、後で集約や可視化ができるようにします。Dev Toolsで実行してください：

PUT dashboard-views
{
  "mappings": {
    "properties": {
      "captured_at": {
        "type": "date"
      },
      "dashboard_id": {
        "type": "keyword"
      },
      "dashboard_name": {
        "type": "keyword"
      },
      "view_count": {
        "type": "integer"
      }
    }
  }
}

IDと名前にkeywordマッピングを使用すると、アグリゲーションが可能になります。view_countのためにintegerを使用することは安全なデフォルト設定です。Kibanaはカウンターを毎日リセットするため、32ビットの制限（1日で20億回以上のビュー）に達することは現実的な懸念事項ではありません。数値演算も引き続きサポートしており、max、avg、minなどが含まれます。

ステップ3: ワークフローを作成する

Stack Management > Workflows > New Workflowに移動し、次のワークフローのYAML構成を貼り付けます。

name: dashboard-views-ingestion
triggers:
  - type: scheduled
    with:
      every: 30m

steps:
  - name: fetch_dashboard_views
    type: kibana.request
    with:
      method: GET
      path: >-
        /api/saved_objects/_find?type=usage-counter&per_page=10000&filter=usage-counter.attributes.domainId:"dashboard"%20and%20usage-counter.attributes.counterType:"viewed"

  - name: index_each_dashboard
    type: foreach
    foreach: "{{ steps.fetch_dashboard_views.output.saved_objects }}"
    steps:
      - name: fetch_dashboard_name
        type: kibana.request
        with:
          method: GET
          path: /api/saved_objects/dashboard/{{ foreach.item.attributes.counterName }}
        on-failure:
          continue: true

      - name: index_doc
        type: elasticsearch.request
        with:
          method: POST
          path: /dashboard-views/_doc
          body:
            dashboard_id: "{{ foreach.item.attributes.counterName }}"
            dashboard_name: "{{ steps.fetch_dashboard_name.output.attributes.title }}"
            view_count: "${{ foreach.item.attributes.count | plus: 0 }}"
            captured_at: "{{ execution.startedAt | date: '%Y-%m-%dT%H:%M:%SZ' }}"

次のセクションでは、ワークフローをステップごとに分解していきます。

ワークフローの仕組み

トリガー

ワークフローは30分ごとにスケジュールされたトリガーで実行されます。これにより、APIに負担をかけずに時系列データが得られます。

ダッシュボードビューを取得

kibana.requestを使ってKibanaの保存済みオブジェクトAPIを呼び出します。認証の設定は不要です。ワークフローエンジンは実行コンテキストに基づいて適切なヘッダーを自動的に添付します。

index_each_dashboard (foreach)

前のステップで返された saved_objects 配列を反復します。各反復の現在の項目は foreach.itemとして利用可能です。ループ内では、各ダッシュボードごとに2つの入れ子手順を実行します。

1. fetch_dashboard_name：

人間が読み取れるダッシュボードのタイトルを GET /api/saved_objects/dashboard/{id} を呼び出して解決します。on-failure: continue: true を追加することで、ダッシュボードが削除されてもビューカウンターが残っている場合、ループが継続して全体の実行が失敗しないようにします。

2. index_doc：

各ドキュメントをPOST /dashboard-views/_doc（明示的なIDなし）でインデックス化することで、Elasticsearchが自動でIDを生成します。これにより、毎回の実行時に新しいドキュメントが作成され、以前のスナップショットを上書きするのではなく、時間の経過とともにビューカウントの履歴が構築されます。

次の2点にご注意ください。

• captured_atフィールドは日付フィルターを使ってタイムスタンプをISO 8601としてフォーマットします。それなしでは、値はJavaScriptの日付文字列として出力され（例：Tue Mar 10 2026 05:03:47 GMT+0000）、Elasticsearchは日付としてマップしません。
• view_countは数値型を保持するために${{ }}構文を| plus: 0と共に用います。{{ }}を使うと文字列としてレンダリングされ、ダッシュボードでの計算操作ができなくなります。

UIでは、各ワークフローステップを快適にデバッグできます。

ステップ4：統計ダッシュボードを構築

ワークフローが数回実行されてデータが収集されたら、dashboard-views Data viewを使用してKibanaで新しいダッシュボードを作成します。

まずは以下のパネルから始めましょう：

• トップのダッシュボード（閲覧数別）： X軸にdashboard_name、Y軸にlast_value(view_count)を持つ棒グラフを使用します。これはダッシュボードごとの現在の日次閲覧数を示しています。
• 時間経過に伴うビュー：X軸にcaptured_at、Y軸にlast_value(view_count)を用いた折れ線グラフを使用し、dashboard_nameで分類されます。各実行が新しいドキュメントを追加するため、重複を合計するのではなく、最後の値を使用して時間バケットごとのピークカウントを取得します。
• 現在のスナップショット：すべてのダッシュボードの最新のビュー数を表示するには、最新のcaptured_at を含むデータテーブルを使用します。

各ワークフローが新しいドキュメントを作成するため、時間範囲でフィルタリングして特定の期間のアクティビティを分析したり、週ごとの比較を行ったり、ダッシュボードのビューしきい値を下回ったときにアラートを設定したりすることができます。

まとめ

Elastic Workflowsは、ソース（Kibana API）と送信先（Elasticsearch）の両方がネイティブであるため、認証管理が全く必要なく、この種の定期的なデータ収集に適しています。ワークフローエンジンはkibana.requestとelasticsearch.requestのステップで認証を自動的に処理するため、記述するのはロジックだけです。

資料

• Elastic Workflows
• Kibana API

Elasticsearchは、遅れて到着するメトリクスを拒否していました。これらの拒否により、パイプラインが遅延し、結果としてより多くの遅延データが発生し、さらに多くの拒否を引き起こしました。最終的にパイプラインは完全に停止しました。

復旧のためには、スナップショットからの復元、データの再インデックス作成、データ取り込みパイプラインの再設計が必要でした。

根本的な原因はインデックスライフサイクル管理（ILM）自体ではなく、時系列データストリーム（TSDS）と、それらが時間的制約のあるバッキングインデックスを強制する方法にありました。

TSDSは指標のストレージ要件を40〜70％削減できますが、TSDSを効率的にするアーキテクチャの変更により、時間の経過とともにインデックスの動作も変わります。これらの変更は、ILMポリシーを設計する時、またはインジェストパイプラインで遅れて到着するデータが生成される可能性がある場合に重要です。

TL;DR

TSDSを使用する場合：

• バックアップインデックスは、特定の時間枠内でのみ文書を受け付けます。
• 遅延データがインデックスがColdまたはFrozen状態に移行した後に取り込まれた場合、Elasticsearchはそれらのドキュメントを拒否するか、設定されている場合は障害ストアにルーティングします。

デザインルール：

warm_min_age > rollover_max_age + maximum_expected_lateness

時系列データストリームとは何ですか？

時系列データストリーム（TSDS）は、メトリクスデータに最適化された特殊なデータストリームです。データは関連するドキュメントが同じシャード内に配置されるようにルーティングされ、クエリと検索のための最適化が行われます。Elasticsearchは以下の方法で行います：

各文書には以下が含まれます。

• 1つのタイムスタンプ。
• 時系列を識別するディメンションフィールド。
• 測定値を表すメトリックフィールド。

例：

• ホストあたりのCPU使用率。
• サービスごとのリクエスト遅延。
• センサーごとの温度測定値。

ディメンションは測定したい対象を特定し、メトリクスは時間とともに変化する値を表します。

ディメンション

ディメンションは測定対象を表します。

例：

host.name
service.name
container.id

それらをマッピングで次のように定義します：

time_series_dimension: true

メトリクス

メトリクスは数値を表し、以下によって定義されます。

time_series_metric

一般的なメトリクスの種類：

• ゲージ：増減する値。
• カウンター：リセットされるまで増加する値。

Elastic Agentは主にメトリクスおよびログデータを収集するため、TSDSのインデックスを手動で有効にしていなくても、クラスター内に存在している場合があります。

_tsidフィールド

Elasticsearchは内部的にディメンションフィールドから _tsid 値を生成します。これにより、同一のディメンションを持つドキュメントを同じシャードにルーティングすることができ、以下が改善されます：

• 圧縮。
• クエリのローカル環境。
• アグリゲーションのパフォーマンス。

主な違い：時間制限付きバッキングインデックス

従来のデータストリームは常に最新のバッキングインデックス（書き込みインデックスと呼ばれる）に書き込みますが、TSDSは異なる動作をします。

各TSDSバッキングインデックスには定義された時間ウィンドウがあり、そのウィンドウ内に収まる@timestamp値を持つドキュメントのみを受け入れます：

GET _data_stream/my-metrics-data-stream


     "index_mode": "time_series",
     "time_series": {
       "temporal_ranges": [
         {
           "start": "2026-01-15T14:35:50.000Z",
           "end": "2026-03-16T11:34:40.000Z"
         }
       ]
     }

ドキュメントがインデックス化されると、Elasticsearchはそれをタイムスタンプに関わるバッキングインデックスにルーティングします。これは、従来のインデックスとは異なり、TSDSが複数のバッキングインデックスに同時に書き込む可能性があることを意味します。

例：

• リアルタイムデータ → 最新のインデックス。
• 遅延データ → その期間をカバーする以前のインデックス。

遅延データに対応する設計方法

実際のインジェストパイプラインは、ほとんどの場合、完全に期限内に指標を届けるわけではありません。メトリクスは、ネットワークの停止、途中のバックログ、バッチのインジェスト、およびエッジデバイスの損失（これらのデバイスは再接続し、キャッチアップを始めます）によって遅延する可能性があります。

従来のインデックスは、静かにその遅延を吸収しますが、TSDSはしません。

ドキュメントのタイムスタンプが書き込み可能なバッキングインデックスの範囲外にある場合、Elasticsearchはそれを拒否します。これは、ILMポリシーが遅延データを考慮する必要があることを意味します。

重要な制約

バッキングインデックスは遅延データを受け入れられるだけの期間、書き込み可能な状態を維持する必要があります。

実際には、これは次のことを意味します。

time_until_readonly > maximum_expected_lateness

ILMはロールオーバーからの時間経過を測定するため、運用ルールは次のようになります。

warm_or_cold_min_age > rollover_max_age + maximum_expected_lateness

たとえば、メトリクスが最大6時間遅延する可能性がある場合、インデックスはロールオーバー後少なくとも6時間は書き込み可能な状態を維持する必要があります。

この制約を考慮しなかったことが、前述のインジェスト障害の正確な原因でした。遅れて到着したデータは、既にColdティアにあり、そのため書き込みがブロックされていた以前のインデックスに向けられていました。

拒否されたドキュメントの処理

TSDS がドキュメントを拒否すると、Elasticsearch は、タイムスタンプが書き込み可能なインデックスの範囲内にないことを示すエラーを返します。インジェストパイプラインがそのエラーをどのように処理するかによって、データを失うか、インジェストが停止するかが決まります。

拒否されたドキュメントを処理する主要なメカニズムは、障害ストアです。

障害ストア（Elasticsearch 9.1以降で推奨）

Elasticsearch 9.1では、拒否されたドキュメントを自動的に格納するfailure storeが導入されました。Elasticsearchは、クライアントにエラーを返す代わりに、失敗したドキュメントをデータストリーム内の専用の障害インデックスに書き込みます。

障害の調査には以下の方法があります。

GET metrics-myapp::failures/_search

障害ストアを使用することで、拒否エラーによるインジェストパイプラインの停止を防ぎつつ、障害データを分析または再インデックスのために保存します。

拒否される問題の監視

遅れて到着する問題は通常、最初にインジェスト異常として現れます。最初は、以下によって気付く場合があります：

• インデキシングレートの突然の低下。
• 拒否されたドキュメントの急増。
• 障害ストアエントリ数の増加。
• パイプラインの入力数と出力数の不一致。

これらの兆候に基づいて警告を発することで、オペレーターはパイプラインが停止する前に問題を検知することができます。ワークフロー、機械学習ジョブ、およびその他のメカニズムを使用して、検出と通知を自動化できます。

TSDS + ILMの移行チェックリスト

メトリクスクラスターをTSDSに移行する場合、ILM階層化を導入する場合、またはメトリクスがデフォルトでTSDSであるElasticsearchバージョンにアップグレードする場合は、まずこれらの項目を確認してください。

1. インジェストレイテンシの測定

ILMの方針を変更する前に、以下を決定してください。

• 通常のインジェスト遅延。
• 最悪の場合、インシデント時の遅延。
• バッチパイプラインによる遅延。

ILM設計は、現実的な最大限の遅延に対応する必要があります。

2. インデックス付けの時間ウィンドウを検証する

TSDSのバッキングインデックスを調べます。

GET _data_stream/

以下について探します：

• time_series.start_time
• time_series.end_time

これらの制限が、どのインデックスがドキュメントを受け入れられるかを決定します。これらのウィンドウを理解することで、データがどのくらい遅れていても拒否されないのかを判断できます。

3. 遅延データを考慮してHotティアのサイズを調整する

遅延データに対しても、バッキングインデックスが書き込める状態を保ちます。

運用ルール：

• warm_min_age > rollover_max_age + maximum_expected_lateness

メトリクスが6時間遅れて届く場合、インデックスは少なくとも6時間は書き込める状態を維持する必要があることに留意してください。

4. 拒否されたドキュメントの処理方法を決定する

TSDSを有効にする前に以下のストラテジーを選択します：

• 障害ストア（Elasticsearch 9.1以降で推奨）。
• Logstashのデッドレターキュー。
• 到着が遅れた場合のフォールバックインデックス。
• 限定的なデータ損失を受け入れる。

5. インジェストの正常性を監視する

以下のアラートを追加します：

• インデキシングの速度低下。
• 却下された書類。
• ストアの拡大失敗。
• パイプラインの入力と出力の不一致。

遅延データの問題は、多くの場合、インジェスト時の異常として最初に現れます。

まとめ

時系列データストリームは、メトリックワークロードに対して主要なストレージとパフォーマンスの改善を提供しますが、重要なアーキテクチャ上の変更も導入します。バッキングインデックスには時間的な制約があり、これがILMの動作に影響します。

TSDSを使用する場合：

• インデックスは、遅延データを受け入れられるだけの期間、書き込み可能な状態を維持する必要があります。
• インジェストパイプラインは、拒否されたドキュメントを安全に処理する必要があります。

留意する重要なルールは次の通りです：

warm_min_age > rollover_max_age + maximum_expected_lateness

その制約に基づいてILMポリシーを設計すると、TSDSはメトリクスのワークロードに非常に適しています。

無視した場合、インジェストパイプラインがその時間的制約によって機能不全に陥る可能性があります。

最初のクエリ

まず、Elasticsearchインデックスにマップする普通のCLRオブジェクト（POCO）を定義します。プロパティ名は、標準的なSystem.Text.Json属性（[JsonPropertyName]など）または設定されたJsonNamingPolicyを通じてES|QL列名に解決されます。クライアントの他の部分に適用されるソースシリアル化ルールは、ここでも同様に適用されます。

using System.Text.Json.Serialization;

public class Product
{
    [JsonPropertyName("product_id")]
    public string Id { get; set; }

    public string Name { get; set; }

    public string Brand { get; set; }

    [JsonPropertyName("price_usd")]
    public double Price { get; set; }

    [JsonPropertyName("in_stock")]
    public bool InStock { get; set; }
}

型を指定すると、クエリは次のようになります。

var minPrice = 100.0;
var brand = "TechCorp";

await foreach (var product in client.Esql.QueryAsync(q => q
    .From("products")
    .Where(p => p.InStock && p.Price >= minPrice && p.Brand == brand)
    .OrderByDescending(p => p.Price)
    .Take(10)))
{
    Console.WriteLine($"{product.Name}: ${product.Price}");
}

プロバイダーはこれを次のES|QLに変換します。

FROM products
| WHERE (in_stock == true AND price_usd >= ?minPrice AND brand == ?brand)
| SORT price_usd DESC
| LIMIT 10

いくつか注意すべき点があります。

• プロパティ名の解決： p.Priceは[JsonPropertyName] 属性のためprice_usdになり、p.BrandはデフォルトのcamelCase命名規則に従って brandになります。
• パラメーターのキャプチャ：C#変数 minPriceとbrandは、名前付きパラメーター（?minPrice、?brand）としてキャプチャされます。これらはJSONペイロード内のクエリ文字列とは別に送信されるため、インジェクション攻撃を防ぎ、サーバー側のクエリプランのキャッシュを可能にします。
• ストリーミング：QueryAsync<T>はIAsyncEnumerable<T>を返します。Elasticsearchからデータが到着すると、行は1つずつマテリアライズされます。

また、実行せずに生成されたクエリとそのパラメーターを検査することもできます。

var query = client.Esql.CreateQuery()
    .Where(p => p.InStock && p.Price >= minPrice && p.Brand == brand)
    .OrderByDescending(p => p.Price)
    .Take(10);

Console.WriteLine(query.ToEsqlString());
// FROM products | WHERE (in_stock == true AND price_usd >= 100) | SORT price_usd DESC | LIMIT 10

Console.WriteLine(query.ToEsqlString(inlineParameters: false));
// FROM products | WHERE (in_stock == true AND price_usd >= ?minPrice AND brand == ?brand) | SORT price_usd DESC | LIMIT 10

var parameters = query.GetParameters();
// { "minPrice": 100.0, "brand": "TechCorp" }

これはどのように機能するのでしょうか？LINQ の簡単なおさらい

LINQプロバイダーを可能にするメカニズムは、IEnumerable<T>とIQueryable<T>の区別にあります。

.Where(p => p.Price > 100) を IEnumerable<T> 上で呼び出すと、ラムダは Func<Product, bool> にコンパイルされます。これは、ランタイムがインプロセスで実行する通常のデリゲートです。これはLINQ-to-Objectsです。

同じメソッドを IQueryable<T> で呼び出すと、C#コンパイラはラムダを Expression<Func<Product, bool>> でラップします。これは実行可能な形式ではなく、コードの構造を表すデータ構造です。式ツリーは実行時に検査、分析、および別の言語への変換を行うことができます。

// IEnumerable: the lambda is a compiled delegate
IEnumerable local = products.Where(p => p.Price > 100);

// IQueryable: the lambda is an expression tree, a data structure
IQueryable remote = queryable.Where(p => p.Price > 100);

IQueryProviderインターフェースは拡張ポイントです。どのプロバイダーでも、これらの式ツリーをターゲット言語に変換するために CreateQuery<T> と Execute<T> を実装できます。Entity FrameworkはSQLを発行するためにこれを使用します。LINQからES|QLへのプロバイダーはこれをES|QLの生成に使用します。

上記のクエリの式ツリーは次のようになります。

例のクエリに対する式ツリー。

ツリーは内側から外側にネストされています。Takeが OrderByDescendingをラップし、これがWhereをラップし、これがFrom, をルート定数EsqlQueryable<Product> をラップします。Where述語自体がBinaryExpressionノードのサブツリーであり、&&、>=、および==演算子に対してMemberExpressionリーフがプロパティアクセス用、minPriceおよびbrand変数用のクロージャキャプチャ用に存在します。これは、プロバイダーが最終的なES|QLを生成するために使用するデータ構造です。

内部構造：変換パイプライン

LINQ式からクエリ結果までの経路は、6段階のパイプラインをたどります。

データ変換パイプラインの概要。

1. 式ツリーのキャプチャ

.Where()、.OrderBy()、.Take()などの演算子をIQueryable<T> に連鎖させると、標準のLINQインフラストラクチャーが式ツリーを構築します。EsqlQueryable<T> はIQueryable<T> を実装し、EsqlQueryProvider に委譲します。

2. 変換

クエリが実行されると（列挙、 ToList()の呼び出し、またはawait foreach)使用によって）、 EsqlExpressionVisitorは式ツリーを内側から外側へと走査します。各LINQメソッド呼び出しを専門のビジターに送信します。

翻訳中、式で参照されるC#変数は名前付きパラメーターとしてキャプチャされます。

3. クエリモデル

ビジターは直接文字列を生成しません。代わりに、QueryCommandオブジェクト、すなわち不変の中間表現を生成します。FromCommand、WhereCommand、SortCommand、およびLimitCommandの各々が、1つのES|QL処理コマンドを表しています。これらはEsqlQueryモデルに集められます。

クエリモデルとコマンドパターン。

この中間モデルは、式ツリーと出力形式の両方から切り離されています。フォーマット前に検査、傍受（IEsqlQueryInterceptor経由）、または修正が可能です。

4. フォーマット

EsqlFormatter 各QueryCommandを順番に訪問し、最終的なES|QL文字列を生成します。各コマンドは1行になり、ES|QLが処理コマンドを連鎖させるために使用するパイプ (|) 演算子で区切られます。特殊文字を含む識別子は自動的にバッククォートでエスケープされます。

5. 実行

フォーマットされたES|QL文字列とキャプチャされたパラメーターは、JSONペイロードとしてElasticsearchの/_queryエンドポイントに送信されます。IEsqlQueryExecutorインターフェースはトランスポートレイヤーを抽象化し、ここで階層型パッケージアーキテクチャが登場します。

6. マテリアライズ

EsqlResponseReader JSON応答をストリーム化し、結果セット全体をバッファリングせずに処理します。ColumnLayoutツリーは、1クエリにつき1回事前に計算され、フラットなES|QL列名（address.street、address.cityなど）をネストされたPOCOプロパティにマップします。各行はTインスタンスに組み立てられ、 IEnumerable<T> または IAsyncEnumerable<T>によって1行ずつ生成されます。

レイヤーアーキテクチャ

LINQ to ES|QL機能は、以下の3つのパッケージに分かれています。

パッケージアーキテクチャー。Elastic.Esql は純粋な変換エンジンです。HTTPへの依存関係は一切なく、式ビジター、クエリモデル、フォーマッター、レスポンスリーダーが含まれています。スタンドアロンで使用すると、Elasticsearch接続がなくてもES|QLクエリを構築および検査できます。これは、テスト、クエリロギング、または独自の実行レイヤーの構築に役立ちます。

// Translation-only: no Elasticsearch connection needed
var provider = new EsqlQueryProvider();
var query = new EsqlQueryable(provider)
    .From("products")
    .Where(p => p.InStock)
    .OrderByDescending(p => p.Price);

Console.WriteLine(query.ToEsqlString());
// FROM products | WHERE in_stock == true | SORT price_usd DESC

Elastic.Clients.Esql は軽量なスタンドアロンのES|QLクライアントです。Elastic.Transportを経由してElastic.Esql上にHTTP実行を追加します。もしアプリケーションが他のElasticsearch APIではなく、ES|QLのみを必要とする場合、これが最小限の依存関係オプションです。

Elastic.Clients.Elasticsearch は完全なElasticsearch .NETクライアントです。また、Elastic.Esql を基盤とし、client.Esql名前空間を通じてLINQプロバイダーを公開します。これはほとんどのアプリケーションで推奨されるエントリーポイントです。

どちらの実行層パッケージも、変換と転送をつなぐ戦略インターフェースであるIEsqlQueryExecutorの独自の実装を提供します。

これら3つのパッケージはすべて、ソース生成のJsonSerializerContextと併用する場合、ネイティブAOTと互換性があります。完全なクライアントについては、Native AOTのドキュメントをご覧ください。

基本を超えて

上記の例では、フィルタリング、ソート、ページネーションについて説明しています。このプロバイダーはより幅広い操作をサポートしています。

アグリゲーション

GroupBySelectの集約関数と組み合わせるとES|QL STATS ... BYに変換されます。

var stats = client.Esql.Query(q => q
    .GroupBy(p => p.Brand)
    .Select(g => new
    {
        Brand = g.Key,
        Count = g.Count(),
        AvgPrice = g.Average(p => p.Price),
        MaxPrice = g.Max(p => p.Price)
    }));

// -> FROM products | STATS COUNT(*), AVG(price_usd), MAX(price_usd) BY brand

予測

Select匿名型を持つと、 EVAL、 KEEP、 RENAME コマンドが生成されます。

var query = client.Esql.CreateQuery()
    .Select(p => new { ProductName = p.Name, p.Price, p.InStock });

// -> FROM products | KEEP name, price_usd, in_stock | RENAME name AS ProductName

豊富な関数ライブラリ

80以上のES|QL関数が EsqlFunctionsクラスを通じて利用可能で、日付/時間、文字列、数学、IP、パターンマッチング、スコアリングをカバーしています。標準的なMath.*およびstring.*メソッドも変換されています。

.Where(p => p.Name.Contains("Pro"))       // -> WHERE name LIKE "*Pro*"
.Where(p => EsqlFunctions.CidrMatch(      // -> WHERE CIDR_MATCH(ip, "10.0.0.0/8")
    p.IpAddress, "10.0.0.0/8"))

ルックアップ結合

クロスインデックス検索はES|QL LOOKUP JOINに変換されます。

var enriched = client.Esql.Query(q => q
    .LookupJoin(
        "category-lookup-index",
        product => product.Id,
        category => category.CategoryId,
        (product, category) => new { product.Name, category!.CategoryLabel }));

未加工のES|QLエスケープハッチ

LINQプロバイダーでまだサポートされていないES|QL機能については、生のフラグメントを追加できます。

var results = client.Esql.Query(q => q
    .Where(p => p.InStock)
    .RawEsql("| EVAL discounted = price_usd * 0.9"));

サーバー側の非同期クエリ

実行時間の長いクエリについては、サーバー上でバックグラウンド処理を行うように設定します。

await using var asyncQuery = await client.Esql.SubmitAsyncQueryAsync(
    q => q.Where(p => p.InStock),
    asyncQueryOptions: new EsqlAsyncQueryOptions
    {
        WaitForCompletionTimeout = TimeSpan.FromSeconds(5),
        KeepAlive = TimeSpan.FromMinutes(10)
    });

await asyncQuery.WaitForCompletionAsync();
await foreach (var product in asyncQuery.AsAsyncEnumerable())
    Console.WriteLine(product.Name);

サーバー側の非同期クエリは、通常のタイムアウトしきい値を超える可能性のある長時間実行される分析クエリや大規模データセットの処理、あるいはロードバランサー、APIゲートウェイ、プロキシなど、厳格なHTTPタイムアウトを強制するタイムアウトに敏感な環境で特に役立ちます。非同期クエリは、結果の取得から提出を切り離すことで接続切断を回避します。

はじめに

LINQ to ES|QLは次のバージョンから利用可能です。

• Elastic.Clients.Elasticsearch v9.3.4 (9.x ブランチ)
• Elastic.Clients.Elasticsearch v8.19.18（8.xブランチ）

NuGetからのインストール：

dotnet add package Elastic.Clients.Elasticsearch

エントリーポイントはclient.Esqlにあります。

クエリオプション、複数フィールドへのアクセス、ネストされたオブジェクト、複数値フィールドの処理など、機能の詳細についてはLINQ to ES|QLのドキュメントを参照してください。

まとめ

LINQ to ES|QLは、C# LINQの完全な表現力をElasticsearchのES|QLクエリ言語にもたらし、クエリ文字列を手作業で作成することなく、厳密に型付けされた構成可能なクエリを書くことができます。自動パラメーターキャプチャ、ストリーミングマテリアライゼーション、スタンドアロン変換から完全なElasticsearchクライアントまで拡張できる階層型パッケージアーキテクチャーにより、あらゆる規模の.NETアプリケーションに自然に適合します。最新のクライアントをインストールし、LINQ式をインデックスに向け、残りはプロバイダーに任せましょう。

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

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

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

• Elasticsearch 9.2+用Elastic Agent Builder MCPサーバー
• 旧バージョン向けのElasticsearch MCPサーバー（Python）

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クライアントを統合するための手順を説明します。

1. Elasticsearch 用の MCP サーバーを設定してください。
2. MCPサーバーをClaude Desktopにロード
3. 試してみてください。

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です。

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

そこで、Elasticは読み取り専用のダッシュボードを開発しました。求めていたコントロールが獲得でき、安心してダッシュボードを共有できます。編集アクセス権を持つ別の人が変更したり壊したりすることを心配する必要はありません。

注：読み取り専用の権限は、Elastic Cloud ServerlessおよびElastic Cloud Hosted、Elastic Self-Managedのバージョン9.3以降で利用可能です。

「すべてのユーザーが編集可能」権限が妨げになる場合

Kibanaにおいて、共有は通常、スペースレベルの権限を意味していました。誰かがスペースでダッシュボードを作成できる場合、他の人のダッシュボードも編集または削除できます。コラボレーションにとっては便利ですが、場合によってはそうとも言い切れません。たった一度の意図しない編集が、誤った判断、信頼の喪失、そして多大な後始末へと連鎖的に影響を及ぼす可能性があります。

ダッシュボード名に「read-only」と入れて皆が気づくことを期待するとか、タグを付けてうまくいくことを祈るといった回避策もあるにはありますが、期待と権限モデルはイコールではありません。必要なのは、スペースから全員を締め出すことなくダッシュボードをロックするための現実的な手段でした。

問題の実例

DebとKevinはどちらも、オペレーションスペース内のログ監視ダッシュボードへの編集権限を持っています。Kevinがチャートにいくつか変更を加えます。Debがダッシュボードに戻ると、数字は彼女が提示したものと一致しませんでした。彼女は（多くの場合記憶を頼りに）何が変更されたのかを突き止め、それを修正し、どれだけの報告書が誤ったデータで送信されたのかを考えなければならなくなります。

読み取り専用ダッシュボード：理にかなった所有権と制御

読み取り専用のダッシュボードでは、他のユーザーがダッシュボードを編集できるかどうかを管理できます。ダッシュボードを共有する際、編集（デフォルト：従来どおり）または閲覧を選択します。閲覧モードでは、あなた（とKibana管理者）のみが変更または削除できます。他のユーザーは開いて利用できますが、変更することはできません。

手に入るもの

• ダッシュボードの整合性：閲覧モードでは、スペースで編集アクセス権を持つ他のユーザーはダッシュボードを変更または削除できません。操作を試みると、ロックされているというメッセージが表示されます。グラフとロジックは設定した状態のまま維持されます。
• コントロールを維持：コントロールは所有者が維持し、いつでも編集、改良、更新が可能です。閲覧専用として共有しても、自分がアクセスできなくなるわけではありません。他の全員が表示できるバージョンが固定されるだけです。
• 柔軟なライフサイクル： ダッシュボードはいつでも「編集可能」に戻すことができます。また、Kibanaの管理者は引き続きすべてのダッシュボードを管理できます（所有者が退職した場合など）。行き止まりになることはありません。

最終決定済みの、業務上極めて重要なダッシュボードを広く共有しても、その一貫性が維持されることが保証されます。これは、Serverlessを含むすべてのElasticのティアとサービスで利用可能です。

役割と可能な操作

クイックリファレンス（役割別）：

• ダッシュボードの所有者：作成者として、完全な編集権限があります。
• Kibana管理者：すべてのダッシュボードを管理できます。
• スペース編集権限を持つユーザー：ダッシュボードの作成と編集が可能ですが、閲覧専用のダッシュボードの編集や削除はできません。
• スペース閲覧権限を持つユーザー：ダッシュボードの表示と一覧表示のみが可能です。

読み取り専用にする方法

新しいダッシュボードを保存する際、または後で共有メニューから「閲覧のみ」に設定できます。

新しいダッシュボードを保存する際

• ダッシュボードを作成し、「保存」をクリックします。
• 「新しいダッシュボードとして保存」モーダルで、「権限」を探します。
• 「編集可能」から「閲覧可能」に変更します。
• ［保存］をクリックします。これで完了です。他のユーザーにとっては閲覧専用となります。

既に所有しているダッシュボードの場合

• ダッシュボードを開いてください。
• 「ダッシュボードを共有」メニューを開きます。

• 共有モーダルで、「権限」を見つけて「閲覧可能」に切り替えます。変更はすぐに適用されます。そのスペースの他のユーザーは、編集や削除ができなくなります。

• 共有アクションにマウスを合わせると、特定のダッシュボードが持つ権限の種類を確認できます。

どのダッシュボードがロックされているかを確認する

メインのダッシュボードリストでは、編集または削除できないダッシュボードの選択用チェックボックスは無効化されています。これにより、閲覧専用の項目を簡単に見分けられます。

ダッシュボードでは、編集アクションも無効になっており、ツールチップが表示され、ダッシュボードが閲覧専用に設定されていることが説明されます。

試してみる

読み取り専用ダッシュボードが利用可能になりました。ダッシュボードを作成し、「閲覧可能」に切り替えて共有します。チームは信頼できる唯一の情報源を得ることができ、あなたは安心感を得られます。タイトルに「編集しないでください」という文言を入れる必要はもうありません。

読み取り専用ダッシュボードをどのように活用されているか、ぜひお聞かせください。コミュニティフォーラムでご意見をお聞かせください。

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

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

初期の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年）。

パーティーは混雑してきています

ピザパーティーを開催する予定だとします。数人の友人が配膳を手伝ってくれていて、ピザは部屋のあちこちに配置されています。あなたは友人一人ひとりにピザを渡し、友人たちは到着する空腹の客にピザを一切れずつ配り始めます。

最初は順調です。数人の客がぽつぽつとやって来て、友達が一切れずつ配ってくれて、みんな幸せそうです。しかし、あなたのサワードウピザの評判が広まると、ドアベルが鳴り続け、ゲストが次々と押し寄せるようになります。すぐに、ペパロニピザを持っている友人の周りに人だかりができ始めます。どうやら皆がそのピザを欲しがっているようです。

ペパロニピザを持ったあなたの友人は、圧倒されています。ゲストは待たされて苛立ち、長い列ができています。一方、マルゲリータピザを持った友人は、誰にも興味を持たれず、ただ突っ立っているだけでした。

さて、どうすればよいでしょうか？

あなたはさらに数枚のペパロニピザを注文し、他の友人に渡します。1人ではなく3人の友人がペパロニピザを持つようになりました。ゲストが分散すれば、一度に3倍ものゲストに対応できるようになります。

パーティーを開催するうちに、いくつかのことが明らかになります。

• すべてのピザが同じように人気なわけではない。需要が高いものもあれば、需要が少ないものもあります。人気のないものの「コピー」を余分に用意する必要はありません。行列ができているタイプのものを余分に用意する必要があります。
• 行列が長くなる前にピザを追加注文する。友人が完全に手に負えなくなり、ゲストが怒って帰ってしまうまで待つようでは、待ちすぎです。人だかりができているのを見たら、ピザを追加で注文するほうがよいでしょう。
• ピザをすぐに捨ててはいけない。ペパロニピザの人だかりが5分ほどまばらになったからといって、混雑が終わったわけではありません。飲み物を補充しているだけかもしれませんし、あるいは単におしゃべりしているだけかもしれません（今でもそういうことがあるかは別にして）。予備のピザを用意しておいてください。しばらく静かな状態が続くようなら、よけておいても構いません。
• 手伝ってくれる友達の数だけピザを配れる。手伝ってくれる友達が4人しかいない場合は、ピザを10枚配っても結果は変わりません。一度に提供できるピザは4枚だけです。ピザの枚数と手伝いの人数を合わせてください。
• 友達が持ち場を離れるときは、その友達のピザの担当を代わる。友達の誰かが外出する必要があったら、すぐにその友達のピザを引き継ぎます。ピザを放置しておくことはできません。誰かに渡すか、しまっておきます。

ピザからレプリカへ

これをElasticsearchに当てはめて考えてみましょう。

この例えでは、ピザはレプリカ（インデックスシャードのコピー）、配膳を手伝ってくれる友人は検索ノード、お腹を空かせたゲストは検索クエリ、そして人だかりができている人気のピザは、検索負荷の高いホットインデックスに相当します。

特定のインデックスに対する検索トラフィックが増加すると、追加のレプリカを作成し、それらを検索ノード全体に分散させます。任意のレプリカは、そのインデックスに対して任意のクエリを処理できます。これは、ペパロニを持っている友人がペパロニの一切れを配るのと同じです。レプリカが多いほどスループットも高くなります。3つのレプリカは、1つのレプリカの3倍のクエリを処理できます。

空腹感の測定

ピザを何枚注文するかを決める前に、参加者の空腹度を把握する必要があります。

Elasticsearchはすべてのシャードの検索負荷を追跡します。これは、シャードが処理している検索アクティビティの量を示す指標です。検索需要全体を把握するために、インデックスのすべてのシャードにわたってこれを集計します。

最も重要なのは相対的な検索負荷です。これは、プロジェクトの総検索トラフィックのうち、各インデックスにどれだけの割合がヒットしているかを指します。あるインデックスが全検索の60％を受け取っている一方で、別のインデックスが5％を受け取っている場合、どこにキャパシティを追加すべきかがわかります。

ピザに隠された数学的な背景

最適なレプリカ数は次の式に従って計算します。

desired_replicas = min(ceil(L × N / (S × X)), N)

定義：

• L = インデックスの相対的な検索負荷（0～1の間）。
• N = プロジェクト内で必要な検索ノードの数。
• S = インデックス内のシャード数。
• X = ホットスポットを回避するためのしきい値（デフォルト値：0.5）。

例として、4つの検索ノード、1つのインデックス、2つのプライマリシャードが検索トラフィックの80％を受け取る場合、以下のようになります。

desired_replicas = min(ceil(0.8 × 4 / (2 × 0.5)), 4)
                 = min(4, 4)
                 = 4

このホットインデックスは検索ノードに分散された4つのレプリカを取得します。

しきい値X（デフォルト値は0.5）は重要です。レプリカシステムが完全に処理能力を超えるまで待つのではなく、半分の処理能力に達した時点で規模を拡大します。余ったピザは、客が帰り始めてからではなく、人だかりができ始めた時に配りましょう。

素早くスケールアップし、ゆっくりとスケールダウン

検索負荷が増えたら、すぐにレプリカを追加します。ユーザーを待たせる理由はありません。

検索負荷が落ちたら、少し待ってからアクションを取ります。レプリカを減らす前に、約30分間需要が安定して低い状態になることを確認する必要があります。（これは、交通量が急激に変動する状況に対処するためのもので、一時的に交通量が減ったからといって、パーティーが終わったわけではないからです。）

レプリカを追加するにはコストがかかるため、これは重要な点です。新しいレプリカは、クエリを効率的に処理する前に、データをコピーし、キャッシュを準備します。レプリカを性急に削除すると、トラフィックが自然に変動するたびに、この初期費用を継続的に支払うことになります。

トポロジー境界を尊重

レプリカは検索ノードの数を超えてはなりません。レプリカの数をノードの数より多くしても何のメリットもありません（ピザを配るのを手伝ってくれる友人の数だけしかピザを配ることができないからです）。

プロジェクトからノードが削除されたら、レプリカ数を即座に削減して一致させます。割り当てられていないレプリカは存在できないため、クールダウンを待つ必要はありません。友人が席を外した瞬間にそのピザを引き継ぎます。

サーバーレスの全体像

レプリカによる検索負荷分散は、他の自動スケーリングシステムと共に機能します。

• 検索自動スケーリングは検索ノードの数を調整します（協力する友人の数）。
• 検索負荷分散のためのレプリカは、インデックスごとのレプリカ数を調整することでトラフィックを分散します（各種のピザが何枚必要かを示すようなものです）。
• データストリームの自動シャード化は書き込みのシャード数を最適化します（各ピザをどのようにカットするかについては前回の投稿をご覧ください）。

重要な設計原則：負荷分散のためのレプリカは、検索の自動スケーリングを直接トリガーしません。その代わりに、検索リクエストをより多くのレプリカに分散させることで、検索ノード全体のリソース利用率を高めることができます。利用率の上昇に伴い、必要に応じて既存の自動スケーリングロジックが作動し、容量が追加されます。負荷分散のためのレプリカを使用することで、自動スケーリングが本来の役割を果たせるようになり、他のノードがアイドル状態になっている間にすべてのトラフィックが単一のレプリカに集中するのではなく、検索ノードが実際に使用されるようになります。

防御側への示唆

どのインデックスが人気になるかを予測する必要はありません。トラフィックパターンが変わってもレプリカを手動で調整する必要はありません。最も取引量の多いインデックスが急激なアクセス集中で処理能力を超えたからといって、午前3時に起きる必要はありません。

システムは、行列ができる場所を監視し、それらのスポットではさらにピザを注文します。コールドインデックスは不要なレプリカにリソースを浪費しません。ホットインデックスは必要な容量を取得します。予算は重要なところに使われます。

まとめ

オートシャーディングに関する記事では、ピザを正しくカットする方法を説明しました。検索のロードバランシングのためのレプリカにより、空腹の群衆が到着した際に、適切な人に十分なピザが行き渡るようにできます。

Elastic Cloud Serverlessを試して、ピザの配送は当社にお任せください。

要件

• 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のような検索エンジンは主に2つの最適化戦略を使用します。

1. 近似検索（Hierarchical Navigable Small World [HNSW]）：すべての文書をスキャンする代わりに、ナビゲーショングラフを構築して、回答の可能性が高い近傍に素早くジャンプします。
2. 量子化：メモリ使用量を削減し、計算速度を向上させるために、ベクトルを圧縮します（例えば、32ビット浮動小数点数から8ビット整数、あるいは1ビットのバイナリ値へ）。

しかし、最適化にはしばしば精度という代償が伴います。

「データを圧縮し、検索中にショートカットを取ると、最高の結果を見逃すのではないか？」「この最適化は検索エンジンの関連性を低下させるのではないか？」といった恐れは正当です。

Elasticの量子化が結果を低下させないことを証明するために、DBpedia-14 データセットを使用して再現可能なテストハーネスを構築し、Elasticsearchのデフォルトの最適化を使用する際に、速度と引き換えにどれだけの精度（具体的には再現率）を犠牲にしているかを正確に計算しました。

要約すると、それはおそらく想定よりもずっと少ないでしょう。こちらのノートブックをチェックして、ぜひご自身でお試しください。

定義（非専門家向け）

コードを見る前に、いくつかの用語について確認しておきましょう。

• 関連性対再現率：関連性 は主観的で（良いものが見つかったか？）、再現率は数学的なものです。データベース内にクエリと完全に一致する文書が10件あり、検索エンジンがそのうち9件を見つけた場合、再現率は90%（または0.9）です。
• 完全一致検索（フラット）：総当たり法とも呼ばれ、検索エンジンはインデックス内のすべての文書をスキャンし、距離を計算します。
  • 長所：100%完璧な再現率。
  • 短所：計算コストが高く、スケール時の処理速度が遅くなる。
• 近似探索（HNSW）：いわゆる「ショートカット」の方法。検索エンジンは HNSW グラフを作成し、グラフを巡回して最も近い隣接点を探します。
  • 長所：非常に高速で拡張性が高い。
  • 短所：グラフの探索が早すぎて停止すると、近傍を見逃す可能性がある。

実験：完全一致と近似探索の比較

再現率をテストするために、テキスト分類モデルのトレーニングと評価によく使用される、14のオントロジークラスにわたるタイトルと要約の大規模なデータセットDBPedia-14データセットを使用しました。具体的には、「Film」カテゴリに焦点を当てます。最適化された生産設定を、数学的に完璧な真値と比較したいと考えました。

この実験では、テキスト表現の業界ベンチマークをリードする最先端の多言語モデルjina-embeddings-v5-text-smallモデルを使用しています。このモデルを選んだ理由は、高性能埋め込みの現在の標準となっているためです。Jina v5の優れた精度とElasticsearchのネイティブ量子化を組み合わせることで、計算効率が高く、検索品質にも妥協のない検索アーキテクチャを実証できます。

二重マッピングを使用したインデックスを設定し、同じテキストを同時に2つの異なるフィールドに取り込みました。

1. content.raw （タイプ: flat）。これにより、ElasticsearchはFloat32ベクトル全体の総当たりスキャンを実行することになります。これにより完全一致の結果が返され、ベースラインとして使用されます。
2. content （タイプ： semantic_text）。デフォルトではHNSW + Better Binary Quantization（BBQ）を使用しています。これは、近似一致のための標準的かつ最適化された生産設定です。

Recall@10 テスト

指標としては、Recall@10を使用しました。

50本のランダムな映画を選び、両方のフィールドに同じクエリを実行しました。

• 完全一致（フラット）検索で上位10個の近傍が ID [1, 2, 3... 10] であると示されている場合。
• また、近似（HNSW）検索では、ID [1, 2, 3... 9, 99] が返されます。
• 上位10位のうち、9位を正しく特定できました。スコアは0.9です。

こちらが使用したマッピングです。

# The "Control Group": Forces exact brute-force scan
"raw": {
    "type": "semantic_text",
    "inference_id": ".jina-embeddings-v5-text-small",
    "index_options": {
        "dense_vector": {
            "type": "flat"
        }
    }
}

結果：成功の「横ばい線」

スケールテストを実行し、完全なデータセットを再読み込みし、1,000～40,000件の文書のインデックスサイズに対してテストしました。

再現率スコアに何が起こったかは以下のとおりです。

結果は驚くほど安定していました。スケールアップしても、近似検索は総当たりの完全一致検索と99％超の確率で一致しました。

なぜこれほど上手くいったでしょう？

ベクトルをバイナリ値に圧縮すると、これよりも精度が低下すると考えられるかもしれません。その理由は、Elasticsearchが検索を処理する方法にあります。

今日のほとんどの埋め込みモデルは、大きなFloat32ベクトルを出力します。探索を効率的にするために、Elasticsearchは高次元ベクトルに対して量子化を使用します。具体的には、バージョン9.2以降、デフォルトでBBQを使用するようになりました。

BBQは再スコアリングメカニズムを採用しています。

1. トラバーサル：検索エンジンは圧縮された（量子化された）ベクトルを使ってHNSWグラフを高速に走査します。ベクトルが小さいため、効率的にオーバーサンプリングを行い、パフォーマンスを損なうことなく、より多くの候補リスト（例えば、類似性の高い上位100件の文書）を収集できます。
2. 再スコアリング：候補が見つかったら、その数件の文書について完全精度の値を取得して、最終的な正確なランキングを計算します。

これにより、量子化による高速な処理と、最終的なソートにおける浮動小数点数の精度という、両方の利点を享受できます。

もっと良くできるでしょうか？

注目すべき点は、ここで確認している結果がデフォルト設定とデータのランダムサンプリングを使用していることです。これは高性能の出発点とお考えください。Jina v5は非常に優れていますが、これらの再現率スコアはすべてのデータセットに対して「万能な」保証ではありません。すべてのデータ収集には独自の特性があり、さらにパフォーマンスを向上させるために調整することは可能ですが、常に自分の特定のデータに対してベンチマーク設定を行い、どこまで性能を引き出せるかを確認する必要があります。

まとめ

これは非常に小規模なテストです。ただし、この演習の目的は埋め込みモデルやBBQを個別に測定することではありません。最小限のセットアップで、データセットの再現率を簡単に測定する方法を示すことです。

このテストを独自のデータで実行したい場合は、こちらのノートブックをチェックして試してみてください。

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

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拡張機能の詳細についてはこちらのプロジェクトリポジトリをご覧ください。

だからこそ、当社は、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の使用によるインパクトの例

セキュリティチーム向け

セキュリティチームは、アラートのトリアージ、検出ルールの調整、ケースの管理といった、同じ運用ワークフローを毎日繰り返しています。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分ほどで完全に構成された環境を構築できます。

プロジェクトを探索：

• Agent Skillsリポジトリ
• agentskills.io 仕様
• Elasticsearchドキュメント
• Elastic Cloudの無料トライアル

前回の記事で見たように、関数呼び出しによってもたらされる一貫性は、単に便利な最適化ではなく、不可欠なものです。構造的なエラーを評価ループから除去したところ、標準的なシナリオ（ティア4データセットなど）の結果が劇的に向上しました。

しかし、答えるべき明白な疑問はまだ残っています。

状況が本当に複雑になってきた場合でも、このアプローチは有効でしょうか？

現実世界におけるエンティティ解決が単純なケースで失敗することはめったにありませんが、名前が言語、文化、文字体系、時代、組織の境界を越える場合に失敗します。人が名前ではなく肩書きで言及されている場合、会社名が変更された場合、音訳が一貫していない場合、そして（スペルではなく）文脈だけが言及と現実世界の実体を結びつける唯一の要素である場合、この方法は失敗します。

そこで、このシリーズの最後の記事として、このシステムにいわば究極のチャレンジを課すこととしました。

なぜこれが究極の挑戦なのでしょうか？

以前の評価では、ますます複雑になるデータセットを用いてシステムをテストしました。前回の記事で触れた第4段階に到達する頃には、すでにニックネーム、称号、多言語名、意味的な参照などが混在する状況になっていました。これらのテストにより、アーキテクチャ自体は健全であることが示されましたが、信頼性の問題、特に不正な形式のJSONが原因で、リコールが抑制されていることがわかりました。

関数呼び出しの仕組みが整ったことで、ようやく安定した基盤ができました。そのおかげで、さらに興味深い質問をする機会が得られました。

1つの統一されたパイプラインで 多くの異なる種類のエンティティ解決問題を一度に処理することは可能でしょうか？

究極のチャレンジデータセットは、まさにその側面を徹底的に追求するために設計されました。

このデータセットは、（ニックネームや音訳といった）単一の困難に焦点を当てるのではなく、 50種類以上の異なる課題タイプを組み合わせています。

• 文化的な命名規則。
• タイトルに基づく参照。
• 事業上の関係性と過去の社名変更。
• 多言語および異文字表記での言及。
• 上記のうち複数を組み合わせた複合的な課題。

重要なのは、この試みが特定の狭い用途向けに最適化することではなく、ルールがエンティティごとに変化した場合でも設計パターンが通用するかどうかをテストすることです。

データセットの概要

究極のチャレンジデータセットは以下で構成されます。

• 個人、組織、機関などの50のエンティティ。
• 構造と言語の複雑さが異なる約60本の記事。
• 大きく以下に分類される51種類の異なるチャレンジカテゴリー。
  • 文化的な命名規則。
  • 肩書きと職務上の背景。
  • 事業と組織間の関係。
  • 多言語および音訳の課題。
  • 複合シナリオとエッジケースのシナリオ。

本シリーズの前半で、生成AIを用いてデータセットを作成することは諸刃の剣であることを確認しました。生成AIがなければ十分な規模と多様性を備えたテストデータを収集することは極めて困難になりますが、このモデルは放置すると、物事をあまりにも単純化しすぎる傾向があります。

例えば、初期世代の検証段階で、モデルに「ロシアの大統領」といったフレーズがウラジーミル・プーチンの明示的な別名として含まれていることが判明しました。それは今日では妥当に思えるかもしれませんが、文脈解決能力をテストするという目的を損なうことになります。記事が1990年代のロシアについて論じている場合はどうなるでしょうか？システムは、ハードコードされたエイリアスに頼るのではなく、文脈から正しいエンティティを推論するべきです。

そのため、このデータセットはショートカットが効かないように意図的に設計されています。システムが意味を推測することが想定されている場合、別名は明示的にリスト化されません。記述的なフレーズはエンティティにあらかじめリンクされていません。正確な一致は、単なるローカルテキストだけでなく、記事レベルの文脈によって決まることが多いです。

重要な注意点：本システムは多様なシナリオにおける機能を実証していますが、これはあくまで教育用プロトタイプです。実際の制裁対象組織の監視を扱う本番システムでは、追加の検証、コンプライアンスチェック、監査証跡、および機密性の高いユースケースに対する特別な処理が必要となります。

これらのシナリオが難しい理由

このシリーズの最初の投稿で、単純であいまいな例「新しいSwiftアップデートが登場しました！」を紹介しました。課題は、「Swift」という単語が、文脈によって複数の現実世界の実体として解釈される可能性があることです。この例はより広範な真実、つまり、自然言語は本質的に曖昧であるということを捉えています。

したがって、エンティティ解決は単なる文字列照合の問題ではありません。人間は日常的に、共通の知識、文化的規範、状況的文脈に頼って参照関係を解決していますが、私たちは自分がそうしていることにほとんど気づきません。

よくあるケースをいくつか考えてみましょう。

• 「大統領」という称号は地政学的・時間的な文脈なしには意味がありません。
• 会社名は、記事がいつ書かれたかによって、親会社、子会社、または以前のブランドを指す場合があります。
• 人名は、言語や文化によって、異なる順序、書体、または音訳で表記されることがあります。
• 同じフレーズでも、文脈によって異なる対象を指す場合があり、システムは一致を受け入れるのと同じくらい確信を持って一致を拒否できなければなりません。

これらすべてを適切に処理する単一のルールセットは存在しないため、このプロトタイプは懸念事項を非常に積極的に分離しています。

• Elasticsearchは候補の範囲を効率的かつ分かりやすく絞り込みます。
• LLMは、判断が必要で、それ自体を説明しなければならない場合にのみ使用されます。
• 検索と推論は別個のステップのままです。

課題の種類が多様化するにつれて、この区分けはさらに重要になります。

システムが特別なケースなしに多様性を処理する仕組み

この評価で最も興味深い結果の一つは、変更しなかった点にあります。

• 日本語名に関する特別なロジックは追加していません。
• アラビア語の父称に関するカスタムルールは追加していません。
• ハードコーディングされたマッピングを過去の会社名に追加していません。

その代わりに、このシステムはシリーズ前半で紹介したものと同じ主要要素に依存していました。

• セマンティック検索のためにインデックス化されたコンテキスト強化エンティティ。
• Elasticsearchでのハイブリッド検索（完全検索、エイリアス、セマンティック）。
• 少数の、明確に定義された一致候補セット。
• 関数呼び出しと最小スキーマによって制約されたLLM判断。

これは、システムの柔軟性が、増え続けるルールのコレクションからではなく、表現とアーキテクチャから生まれることを示唆しています。

システムが成功するのは、適切な候補が取得され、LLMが参照が特定のエンティティにマッピングされる（またはされない）理由を説明できる十分なコンテキストがある場合です。

結果：パフォーマンスの概要

究極のチャレンジデータセットにおいて、システムは以下のような全体的な結果を生み出しました。

• 精度：約91％
• 再現率：約86％
• F1スコア：約89%
• LLM合格率：約72％

チャレンジの種類ごとのパフォーマンス

チャレンジの種類ごとに結果を分解すると、強みと限界が明らかになります。

最も優れたパフォーマンス（F1スコア100%）が見られた分野は以下のとおりです。

• 文字体系間の照合（キリル文字、韓国語、中国語の企業名）。
• ヘブライ語のシナリオ（父称、専門職称、宗教称号、音写）。
• 事業階層構造（航空宇宙、多角化製造業、多部門企業）。
• 職業上の肩書き（学術、軍事、政治、宗教）。
• 複数の文字体系を含む日本語シナリオの組み合わせ。

優れたパフォーマンス（F1スコア80～99％）には以下が含まれます。

• 国際的な政治家（98％）。
• 歴史的な名称変更（90%）。
• 複雑なビジネス階層（89％）。
• 日本の企業名（93％）。
• 異言語間の音訳（86％）。
• アラビア語の父称（86％）。

より困難な分野には以下が含まれます。

• 高度な音訳（中国語、韓国語）：0% F1。
• 特定の日本語シナリオ（敬称、名前の順序、表記体系のバリエーション）：約67% F1。
• 一部のアラビア語のシナリオ（会社名、機関の参考文献）：約40％ F1。

ここで重要なのは、なぜシステムがこれらのケースで機能不全に陥ったのかという点です。失敗の原因は、全体的なアプローチが破綻したことではなく、特定のコンポーネントの限界、特に特定の多言語シナリオにおけるセマンティック検索に使用される高密度ベクトルモデルの限界にありました。

検索と判断が明確に分離されているため、パフォーマンスを向上させるためにシステムを書き換える必要はありません。より高性能な多言語埋め込みモデルの採用、エンティティコンテキストの強化、または検索戦略の洗練により、コアアーキテクチャを変更することなく、これらのカテゴリー全体で結果が向上します。

アーキテクチャーの観点から見ると、それが真の成功指標です。

この結果が設計について教えてくれること

シリーズを振り返ると、いくつかのパターンが際立っています。

• 準備は巧みなマッチングよりも重要です。 エンティティに事前にコンテキストを付加することで、後々の曖昧さを劇的に減らすことができます。
• LLMは、レトリバーではなく、判断者として最も価値があります。したがって、検索を求めるよりも、なぜ一致が意味をなすかを説明するよう求めることの方がはるかに強力です。
• 信頼性が精度を実現します。関数呼び出しは、JSONを整理しただけでなく、取得ステップにすでに潜在していた想起を解放しました。
• 一般化は専門化に勝ります。厳選された少数の抽象化によって、独自のロジックを必要とせずに数十種類の課題に対応できました。

これが、プロトタイプが意図的にElasticsearchネイティブであり、LLMの使用方法が意図的に保守的である理由です。目標は検索を置き換えることではなく、意味が重要な状況において、検索を説明可能なものにすることです。

結びに

究極のチャレンジとは、完璧な指標を追い求めることではなく、より根本的な問いに答えることでした。

透明性が高く、検索優先で、LLMを活用したアーキテクチャは、ルールやブラックボックスに陥ることなく、現実世界のエンティティの曖昧さを処理できるでしょうか？

その回答は、この教育用プロトタイプに関しては「はい」ですが、本番環境での強化、コンプライアンス、監視、データの品質に関する明確な注意事項があります。エンティティの一致が行われた理由を正当化する必要のあるシステムを構築している場合、このパターンは真剣に検討する価値があります。このシリーズを通して、エンティティ解決は必ずしも難解なものではないということが伝われば幸いです。適切に関心事を分離することで、それは論理的に考え、測定し、改善できるものになります。

この研究はまた、より広範なアーキテクチャパターンを示唆しています。浮かび上がってくるのは、古典的な検索拡張生成（RAG）の、わずかではあるが重要な進化です。検索結果を直接生成に供給するのではなく、明示的な評価ステップを導入します。LLMはまず、取得された候補を評価し、妥当性を確認するために使用され、承認された結果のみが生成の強化に使用されます。これは、Generation-Augmented Retrieval-Augmented Generation with Evaluation、つまりGARAGEと名付けられるでしょう。うまい頭字語が嫌いな人なんていませんから。

このパターンは、他にどのような用途で活用できるでしょうか？信頼性、透明性、そして論理的な説明を必要とするシステムは、まさにうってつけの候補と言えます。この分野における今後の研究は、今回得られた成果と同様に説得力のあるものとなるはずであり、コミュニティが今後どのような展開を見せるのか、非常に楽しみです。

次のステップ：試してみましょう

究極のチャレンジが実際に動作する様子をご覧になりたいですか？実際の実装、詳細な説明、実践的な例を含む完全なウォークスルーについては、Ultimate Challenge notebookを参照してください。

完全なエンティティ解決パイプラインにより、本番での使用に必要なコアコンセプトとアーキテクチャが示されています。これを基盤に、透明性と説明可能性を維持しながら、ニュース記事を監視し、エンティティの言及を追跡し、どのエンティティがどの記事に登場するのかについての質問に回答するシステムを構築できます。

HNSWでは、グラフ内の候補ノードを反復的に拡張し、これまでに発見された最も近い近傍の制限されたセットを維持することで検索が進行します。各拡張にはコスト（ベクトル演算、ディスクへのランダムシークなど）がかかり、そのコストに対する限界効用は検索が進むにつれて減少する傾向があります。

HNSWグラフのトラバーサルを最適化する1つの方法は、新しい真の近傍を見つける周辺尤度が増加しない場合に検索を停止することです。このため、Elasticsearch 9.2では、新しい早期終了メカニズムを導入しました。これは、グラフノードを訪問しても一定回数連続して十分な数の新しい最近傍が提供されない場合に、検索プロセスを停止するものです。

この記事では、HNSWの前述の早期終了メカニズムを改良して、さまざまなデータセットやデータ分布に適したものにする方法について説明します。

HNSWでの早期終了

HNSW では、近接グラフ内の候補ノードを反復的に拡張し、これまでに発見された最も近い近傍の制限されたセットを維持して、グラフ全体を訪問するか、早期終了基準を満たすまで、検索が続行されます。

したがって、早期終了は必ずしも最適化ではなく、検索アルゴリズム自体の一部です。停止を決定する瞬間が、効率性と再現率のバランスを決定します。Elasticsearchでは、HNSWのクエリを早期終了させる方法がすでにいくつか存在します。

• 固定された最大数のノードが訪問されます。
• 一定のタイムアウトに達した場合。

これらのルールは単純かつ予測可能ですが、検索が実際に何をしているかにはほとんど関係がありません。また、これらは主に、クエリがエンドユーザーにとって妥当な時間内に完了することを確認するために使用されます。

前回のブログ投稿ではHNSWにおける冗長性の概念を紹介しました。つまり、HNSWが新しい候補ノードを評価し続けても、さらに最も近い近傍が見つからない場合、冗長な計算が発生します。

忍耐度：努力ではなく進歩を測る

忍耐度という概念は、努力ではなく進歩を中心に早期終了を再構築します。

次のように尋ねる代わりに

「何ステップ進んだ？」

新たに次のように問いかけます。

「希望を失うまでに受け入れられる無駄な計算はどれだけかな？」

HNSW検索では、通常、初期の探索によっ上位k候補セットの最高の改善がもたらされます。HNSWグラフ探索の最初のステップでは、アルゴリズムがクエリベクトルにますます近い近傍を検出し続けるため、近傍のセットは継続的に更新されます。時間が経ち、検索が収束するにつれて、これらの改善はまれになります。忍耐度ベースの終了はこのパターンを監視し、改善が一定期間停止した時点で検索を終了します。

実際には、HNSWグラフを訪問する際、候補ノードをホップしながらキューの飽和比も計算します。これは、最新のグラフノードを訪問中に変更されなかった最も近い近傍の割合（または最後の反復中に導入された新しい近傍の数の逆数）を測定します。このような比率が連続した反復処理で大きくなりすぎると、グラフの訪問を停止します。

概念的には、忍耐度はHNSWの検索を収穫逓減プロセスとして扱います。リターンが平坦になると、グラフの調査を継続してもほとんど利益は得られません。

この枠組みは、終了を恣意的な固定された制限ではなく、観察可能な結果に直接結び付けるため、強力です。

このスマートな早期終了手法を使用する利点は、HNSWグラフ探索では、ほぼ完璧な相対再現率を維持しながら、より少数のグラフノードを訪問する傾向があることです。

これを視覚化するために、FinancialQAとQuoraという2つのデータセットと、JinaV3とE5-smallというモデルで、忍耐度に基づく早期終了（ et=staticとラベル付け）で取得した訪問ノードあたりの再現量を、デフォルトのHNSW動作（ et=noとラベル付け）と比較してプロットすることができます。

静的しきい値とHNSWのダイナミクス

実際には、Elasticsearchでは静的しきい値を使用してこれが実装されます。1つのしきい値は、飽和しきい値、つまり、最適ではないと判断される飽和度の比率を指します。もう1つのしきい値は、最適ではないキュー飽和を維持しながら連続して訪問できるグラフノードの数、つまり忍耐しきい値を指します。

Elasticsearch 9.2でこの早期終了戦略を導入したとき、レイテンシーとメモリ消費の面でメリットを得ながら再現率を可能な限り高められるように、保守的なデフォルトを選択することにしました。このため、KNNクエリでは飽和しきい値を100%に、忍耐しきい値を num_candidates の（有界の）30%に設定しています。

多くのシナリオでは、これらの設定はうまく機能しますが、同じ数の近傍を要求する2つのクエリでは、収束動作が根本的に異なる可能性があります。あるクエリは密集した局所的な近傍に遭遇し、すぐに飽和します。他のクエリは競争力のある候補を見つけるまでに、長くまばらな経路を通過しなければなりません。後者は、効果的に処理するのが最も困難であることが判明しました。

その結果、次のようなことに気付くことがありました。

• 簡単なクエリに対する過度の探索。
• 難しいクエリに対する時期尚早の終了。

したがって、固定されたしきい値は収束に関する全体的な仮定をエンコードしますが、HNSWをさまざまなダイナミクスに適応させることができると考えました。

HNSWの早期終了を適応的に

適応的早期終了は、この問題に異なる角度からアプローチします。事前に定義された停止しきい値を強制する代わりに、アルゴリズムが検索のダイナミクス自体からいつ停止するかを推測します。

したがって、2つの連続した候補間のキュー飽和比を比較する代わりに、即時平滑化発見率 $d_{q,i} $（クエリqの最後の訪問iで導入された新しい隣接ノードの数）と、グラフ訪問中のそのような発見率の移動平均$\mu_{q,i}$と標準偏差$\sigma_{q,i}$を導入することにしました（ウェルフォードのアルゴリズムを使用）。これらの発見率に関する統計はクエリごとに計算されるため、この情報をもとに各クエリの忍耐度を判断できます。

以前は静的であったしきい値は、発見率の統計に対して適応的になります。飽和しきい値はローリング平均と標準偏差の合計になり、一方で忍耐力は標準偏差に反比例して適応およびスケーリングされます。

早期終了ルールは変わらず、飽和は即時発見率が適応飽和しきい値より低い場合に発生します。適応的忍耐度よりも大きい連続候補訪問回数にわたって飽和が継続する場合、グラフ訪問は停止します。

こうすることで、KNNクエリの num_candidates パラメーターに依存しない動作（早期終了に関係なく、常に設定されるか、デフォルトのままになる場合がある）が得られ、各クエリとベクトル分布に動的に適応しやすくなります。

適応型戦略（ et=adaptiveとラベル付け）を使用したFinancialQAおよびQuoraでの訪問ノードあたりの再現率は、静的戦略（ et=static ）およびデフォルトのHNSW動作（ et=no ）と比較した場合、高くなっています。

適応的早期終了はElasticsearch 9.3ではHNSWの高密度ベクトルフィールドに対してデフォルトでオンになっています（最終的には同じインデックスレベルの設定でオフにすることができます）。

統合では、データ収集を行うために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))
')

"..."

リクエストは実行前に明示的に構築することができます。これにより、さまざまな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 インプット - Filebeat ドキュメント
• Mito ドキュメント
• Common Expression Language - cel.devウェブサイト
• 統合を作成する - Elastic ドキュメント

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

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

1. 新しいSwiftアップデートが登場しました！開発者たちは新しい機能を試したがっています。
2. 新しいSwiftアップデートが登場しました！新しいアルバムは来月リリースされます。

この追加されたコンテキストにより、「Swift」という名前を正しいエンティティに解決できるはずです。

前回の投稿では、ウォッチリストを設定し、追加のコンテキストでエンティティを充実させました。上記の例を見ると、リストには少なくとも「Taylor Swift」と「Swift Programming Language」の2つのエンティティが必要です。また、テキストからエンティティの言及を抽出する方法も説明しました。これらの例はどちらも「Swift」を抽出します。これらの材料、強化された監視リスト、抽出されたエンティティが揃ったところで、いよいよショーの主役であるエンティティマッチングを紹介する準備が整いました。

注意：これは、エンティティマッチングの概念を教えるために設計された教育用プロトタイプです。本番システムは、異なる大規模言語モデル（LLM）、カスタムマッチングルール、特殊な判断パイプライン、または複数のマッチング戦略を組み合わせたアンサンブルアプローチを使用する可能性があります。

問題：マッチングが難しい理由

人間の言語とは驚くべきものです。その最も興味深い特性の1つは、その無限の創造性です。無限の数の新しい文を生成し、理解することができます。そうであるなら、エンティティ解決において正確な一致が稀なのも不思議ではありません。作家は可能な限り創造的であろうと努めます。エンティティが言及されるたびにフルネームを書いたり読んだりしなければならないとしたら、かなり面倒です。そのため、厳密な一致は簡単ですが、現実には、より洗練されたエンティティ解決アプローチが必要です。それは、人間の作者の無限の創造性に少なくとも部分的には対応できるほどに堅牢なアプローチであるべきです。そのため、私たちは問題を2つのステップに分けます。まずはElasticsearchを使用して大規模な候補を取得し、次にLLMを使用してそれらの候補が実際に同じ現実世界のエンティティを指しているかどうかを判断します。

解決策：透明性の高いLLM判断による3段階のマッチング

私たちはコンピューターの使い方におけるパラダイムシフトの真っ只中にあります。インターネットの台頭がローカルコンピューティングからグローバルに接続されたネットワークへと私たちを導いたように、生成AIはコンテンツ、コード、情報の作成方法を根本的に変えています。実際、このシリーズに付随する教育プロトタイプは、作者の慎重な指示のもと、LLMを使用してほぼ「バイブコーディング」のみで作成されました。これは、LLMが人間の言語に本来備わっている生産性を実現している、あるいは実現するだろうということと同義ではありませんが、エンティティ解決を支援する強力なリソースが手に入ったことを意味します。

生成AIでよく使うパターンは、Retrieval-Augmented Generation（RAG）です。ここにおいて、取得（retrieval）とは、エンティティ候補を取得すること（回答を生成することではない）を意味し、LLMは一致の評価と説明にのみ使用されます。エンドツーエンドのエンティティ解決についてLLMに支援を依頼することもできますが、これは時間と費用の両面でコストのかかるアプローチです。RAGは、より効率的な方法でLLMにコンテキストを提供することでLLMの作業を支援し、それによってLLMがエンティティ解決を効率的に支援できるようにします。

RAGの取得部分については、再びElasticsearchを利用します。まず、正確な一致、エイリアスとの一致、そしてキーワード検索とセマンティック検索を組み合わせたハイブリッド検索という組み合わせを使用して、潜在的な一致を検索します。一致する可能性のある項目が見つかったら、LLMに送信して判断を仰ぎます。LLMは最終的な一致評価者として機能します。また、LLMにその理由を説明させます。これは他のエンティティ解決システムとの重要な差別化要因です。これらの説明がなければ、エンティティ解決はブラックボックスになります。説明があれば、一致にどんな意味があるのか自分で確認できます。

主な概念：3段階マッチング、ハイブリッド検索、透過的なLLM判断

3段階マッチングとは？このプロジェクトの開始時に、セマンティック検索がシステムの重要な一部になるという仮説を立てましたが、すべての一致にこのような高度な検索が必要なわけではありません。効率的にマッチングを見つけるために、私たちは段階的なアプローチを取ります。まず、キーワード検索で正確な一致を確認します。そのような一致が見つかった場合、作業は完了し、先に進むことができます。完全一致が失敗した場合は、エイリアス一致を使用します。このプロトタイプでは、簡素化のために、キーワードとの完全一致によるエイリアスマッチングも行われています。本番環境では、正規化、翻字ルール、あいまい一致、またはキュレートされたエイリアステーブルを使用してこのステップを拡張する場合があります。それでも最初の2つのステップで一致する可能性のあるものが見つからない場合は、Elasticsearchの逆順位融合（RRF）を使用したハイブリッド検索によるセマンティック検索を導入します。

ハイブリッド検索とは？Elasticsearchでは、セマンティック検索を使用して、コンテキストを考慮した意味のある一致を見つけることができます。Elasticsearchは、ベクトル検索とハイブリッド検索に広く使用されています。セマンティック類似性は意味を理解する上で強力ですが、構造化されたフィルタリング（例えば、時間範囲、場所、または識別子による）の代替にはならず、正確な一致が利用可能な場合は多くの場合不必要です。Elasticsearchは語彙検索で名声を博しており、これはセマンティック検索が適さないタスクに最適です。両方のアプローチを最大限に活用するために、単一のハイブリッドクエリで語彙検索とセマンティック検索を併用します。次に、結果をマージして、RRFを使用して最も一致する可能性が高いものを見つけます。このプロトタイプでは、上位2つの結果が、LLM判定に送信できる潜在的な一致となります。

LLM判定を使用する理由とは？LLMの判断と説明により、システムは曖昧さとコンテキストを透過的に処理できます。これは「the president」のような場合において重要です。コンテキストによって複数のエンティティを指す可能性がありますが、システム内でニックネームや文化的なバリエーションをうまく機能させることもできます。最後に、制裁リストからエンティティを識別するなどのミッションクリティカルなタスクを検討する場合、システムを信頼するために、一致が受け入れられた理由を把握する必要があります。重要なのは、LLMはコーパス全体を検索せず、Elasticsearchによって返された少数の候補のみを評価するということです。

実際の結果：LLM推論によるマッチング

あらゆる自然言語処理タスクにおける大きな課題は、期待される結果が何であるかを示す「答えの鍵」となるゴールデンドキュメントを作成することです。これがなければ、システムがタスクをどの程度うまく実行するかを判断することはほぼ不可能ですが、そのようなドキュメントを作成するのは面倒なプロセスになる可能性があります。エンティティ解決のプロトタイプでは、テストに使用できるデータの設定に生成AIを再度利用しました。

まず、ニックネームや翻字などのいくつかのチャレンジタイプを定義し、次にLLMに、システムにとって徐々に大きく、より困難になる階層化されたデータセットコレクションを作成するように依頼しました。データセットの作成は期待していたほど簡単ではありませんでした。LLMでは、正解を得るのがあまりにも簡単すぎるため、「チート」が行われる傾向が強くなりました。例えば、あるチャレンジタイプは意味的なコンテキストに重点を置いています。このタイプには、「ロシアの作家」を「レフ・トルストイ」に解決することなどが含まれます。LLMは誤って「ロシアの作家」を「レフ・トルストイ」の別名として入力したため、一致を見つけるためのハイブリッド検索の必要性がなくなりました。

このような問題を修正するために何度かリファクタリングを行った結果、5つのデータセット層が使用できるようになりました。第1〜4層は徐々に規模が大きくなり、チャレンジの種類も増えました。第5層は「究極のチャレンジ」データセットで、すべてのチャレンジタイプから最も難しい例で構成されていました。すべてのテストデータは包括的な評価ディレクトリで利用可能です。

プロンプトベースのエンティティ解決アプローチを評価するため、私たちは第4層データセットに注目しました。重要な注意点は、エンティティの一致品質に焦点を当てることができるように、評価が制御された実験として実施されたことです。ウォッチリストデータは事前にコンテキストで強化されており、エンティティは事前に記事から抽出され、評価で抽出精度ではなくマッチングに重点が置かれることが保証されました。これにより、一致品質が分離されます。エンドツーエンドのパフォーマンスは、抽出リコールとエンリッチメント品質にも依存します。

評価データセット

第4層の評価データセットは、システムの機能の包括的なテストを提供します。[1]

• 監視リストのエンティティ：さまざまなタイプ（人、組織、場所）にわたる66個のエンティティ。
• テスト記事：実際のエンティティ解決シナリオを網羅した69件の記事。
• 予想される一致数：すべての記事で206件のエンティティが一致すると予想。
• チャレンジタイプ：エンティティ解決のさまざまな側面をテストする15種類のチャレンジタイプ。

データセットに含まれる課題の種類は以下の通りです。

• ニックネーム： 「ボブ・スミス」→「ロバート・スミス」（7つの記事）。
• 称号と敬称：「Dr. Sarah Williams」→「Sarah Williams」（5つの記事）。
• 意味的文脈： 「ロシアの作家」→「レフ・トルストイ」（8 つの記事）。
• 多言語名：異なる文字での名前の取り扱い（6つの記事）。
• 事業体：会社名のバリエーション（7つの記事）。
• 役員紹介： 「Microsoft CEO」→「Satya Nadella」（5つの記事）。
• 政治指導者：タイトルベースの参考文献（5つの記事）。
• イニシャル： 「J. Smith」→「John Smith」（3つの記事）。
• 名前の順序のバリエーション：さまざまな名前の順序付け規則（3つの記事）。
• 切り捨てられた名前：名前の一部一致（3つの記事）。
• 名前の分割：名前がテキストに分割（3つの記事）。
• スペース/ハイフンの欠落：書式のバリエーション（2つの記事）。
• 翻字：文字間の名前の一致（2つの記事）。
• 複合チャレンジ：1つの記事に複数のチャレンジ（6つの記事）。
• 複雑なビジネス：階層的なビジネス関係（5つの記事）。

プロンプトベースのエンティティ解決がどのように機能したか見てみましょう。

全体的なパフォーマンス

結果は、LLMを活用したマッチ評価には大きな可能性があることを示していますが、重大な信頼性の問題も明らかにしています。各候補ペアはLLMによって評価される必要があるため、構造化された出力の失敗により、検索が適切に機能している場合でも受け入れと呼び出しが抑制される可能性があります。

エラー率の問題

このプロトタイプで最初に行うステップは、Elasticsearchを使用して潜在的な一致ペアを作成することであることを思い出してください。これらの潜在的な一致はそれぞれ、LLMによって評価される必要があります。これらすべての一致を効率的に処理するために、LLM呼び出しをバッチ処理します。これにより、APIのコストと待ち時間が削減されますが、出力に不正な形式のJSONが表示されるリスクも高まります。バッチサイズが大きくなると、JSONはより長く複雑になり、LLMが無効なJSONを生成する可能性が高くなります。これがエラー率30%となる原因です。評価では、リクエストごとに5つの一致のバッチサイズを使用しました。この保守的なバッチサイズでも、JSON解析エラーが発生し、評価結果が大幅に歪んでいます。

次のステップ：LLM統合の最適化

セマンティック検索とLLMによる判断を用いてエンティティをマッチングしたことで、完全なエンティティ解決パイプラインが完成しました。ただし、このアプローチでは、モデルの判断は正しいものの、その出力が使用できない場合に、新たな障害モードが発生します。LLM統合を最適化することで、信頼性とコスト効率を向上させることができます。次の投稿では、エラーとコストを削減しながら構造と型の安全性を保証する構造化出力に関数呼び出しを使用する方法について説明します。

はじめましょう

エンティティマッチングの実際の動作を確認したいですか？実際の実装、詳細な説明、実践的な例を含む完全なウォークスルーについては、エンティティマッチングノートブックを参照してください。このノートブックでは、3段階の検索、RRFを使用したハイブリッド検索、LLMを利用した推論による判断を使用してエンティティを一致させる方法を正確に示します。

注意：これは、概念を教えるために設計された教育用プロトタイプです。本番システムを構築するときは、モデルの選択、コストの最適化、レイテンシ要件、品質検証、エラー処理、監視など、教育に重点を置いたこのプロトタイプではカバーされていない追加の要素を考慮してください。

メモ

1. これらのデータセットは合成されたもので教育用に設計されており、実際の課題に近似していますが、単一の本番ドメインを代表するものではありません。

2,000万件の文書コーパスを用いたベンチマークテストの結果、Elasticsearchはフィルタリングされたベクトル検索においてOpenSearchよりも最大8倍高いスループットを実現し、テストしたすべての構成においてより高いRecall@100を達成しました。コンテキストエンジニアリングに必要な要素は高速ベクトル取得だけではありません。ワークフローの反復につれて、チームはハイブリッド検索やフィルタリングなどの強力な関連性制御、操作の簡便性、予測可能なパフォーマンスも必要とするようになります。しかし、エージェントはリクエストごとに取得、推論、取得のループを何度も実行することが多いため、取得の遅延が乗数効果となり、ここでの改善はエンドツーエンドの応答性の向上とコスト削減に直接つながります。

コンテキストエンジニアリングにおいて、取得は一度きりのステップではありません。エージェントとアプリケーションは、クエリを洗練させ、事実を検証し、根拠に基づいたコンテキストを構築し、タスクを完了するために、取得 → 推論 → 取得といったループを繰り返し実行します。このパターンは、エージェント型ワークフローや反復型検索拡張生成（RAG）においてよく見られます。検索はユーザーリクエストごとに何度も呼び出される可能性があるため、応答に遅延が生じ、インフラコストが増加します。

ベクトル検索のパフォーマンスが重要な理由

「15インチのノートパソコンが入る、防水性があり、金曜日までに届く60ドル以下の機内持ち込み用バックパックが必要です」という質問に、店員が答える場面を想像してみてください。

実際の運用環境では、アシスタントがベクトルクエリを1回発行して停止することはほとんどありません。適切なコンテキストを構築するために検索ループを実行し、各ステップは通常、在庫状況、地域、出荷約束、ブランドルール、ポリシー適格性などのフィルターによって制約されます。

ステップ1：意図を解釈し、制約に変換する。

エージェントはリクエストを構造化されたフィルタとセマンティッククエリに変換します。例えば、次のようなものです。

• フィルター：在庫あり、ユーザーの郵便番号に配達可能、金曜日までに配達、価格60ドル未満、有効な出品
• ベクトルクエリ：「機内持ち込み用バックパック 15インチノートパソコン対応 防水」

ステップ2：候補を取得し、絞り込む。

適切な一致を見逃さないように、しばしばバリエーションを加えて検索を繰り返します。

• 「旅行用バックパック 機内持ち込み可能 ノートパソコン用スリーブ」
• 「防水通勤用バックパック 15インチ」
• 「軽量 機内リュック」

各クエリは同じ適格性フィルターを使用します。なぜなら、無関係な項目や利用できない項目を取得することは、コンテキストの無駄になるからです。

ステップ3：詳細を確認し、リスクを軽減するために展開する。

エージェントは、最終的な回答に影響を与える主要な属性を再度確認するために取得を行います。

• 素材と耐水性に関する記述
• 寸法とノートパソコン収納部の適合性
• 返品ポリシーや保証の制約
• 在庫が少ない場合の代替オプション

これは、取得、推論、取得、組み立てという複数段階のコンテキストエンジニアリングです。

コンテキストエンジニアリングにおいてレイテンシと再現率が重要な理由

これらのやり取りには、ユーザーセッションごとに数十回のフィルタリングされたデータ取得呼び出しが含まれる場合があります。それにより、呼び出しごとのレイテンシがエンドツーエンドの応答時間に直接的な乗数となり、低い再現率は追加の再試行を強制したり、エージェントが対象アイテムを見逃す原因となり、回答の質を低下させます。

要点：コンテキストエンジニアリングされたシステムでは、フィルタリングされた近似最近傍法（ANN）は単一のルックアップではありません。これは制約下での反復処理であるため、大規模言語モデル（LLM）が最も目立つ要素である場合でも、ベクトル検索のパフォーマンスはレイテンシ、スループット、コストにすぐに現れます。

ベンチマーク

成果

グラフ2では、各点が1つのテスト構成を表しています。最も良い結果は左上に表示され、これは低いレイテンシで高い再現率が得られることを意味します。Elasticsearchの結果はOpenSearchよりも常に左上に近く、同じワークロード設定下でより優れた速度と精度を示しています。

いくつかの重要な洞察

• s_n_r_value: size_numCandidates_rescoreOversampleの省略形（これらのテストではkとnumCandidatesはnumCandidatesと等しく設定されます）。例えば、 100_500_1 size=100、numCandidates=500、k=500、再スコアオーバーサンプル=1 を意味します。
• 再現率：その構成における測定Recall@100
• 平均レイテンシ（ミリ秒）：クエリごとの平均エンドツーエンドレイテンシ
• スループット：1秒あたりのクエリ数
• 再現率（％）：ElasticsearchとOpenSearchの相対的な再現率向上率（Elasticsearch - OpenSearch）/OpenSearch
• レイテンシXs：OpenSearchの平均レイテンシをElasticsearchの平均レイテンシで割った値
• スループットX：Elasticsearchのスループットをオープンサーチのスループットで割った値

例えば、100_9000_1では、OpenSearchの平均取得時間687ミリ秒に対してElasticsearchは90ミリ秒であり、10ステップの取得ループでは約10×(687-90)=6秒の追加待機時間となります。

全ての結果をご覧ください。

調査手法

Pythonを使ってクエリを送信し、対応タイミングやその他の統計を追跡し、以下のクエリをエンジンに送信しました。ベクター検索エンジンのパフォーマンスは、そのコアパラメータ（考慮する候補の数、再スコアリングの積極性、返されるコンテキストの量など）をどのように調整するかによって決まることを覚えておいてください。これらの設定は、再現率（正解を見つける可能性）とレイテンシ（結果を得るまでの速さ）の両方に直接影響します。

ベンチマークでは、エージェント検索ループで通常調整するのと同じ候補、再スコア、結果サイズの設定を使用し、そのワークロード下でElasticsearchがどのように機能するかを測定しました。その後、同じ設定でOpenSearchをリファレンスとして実行しました。

OpenSearch

GET /_search
{
  "query": {
    "knn": {
      "": {
        "vector": [...],
        "k": ,
        "method_parameters": {
          "ef_search": 
        },
        "rescore": {
          "oversample_factor": 
        },
        "filter": {
          
        }
      }
    }
  },
  "size": ,
  "_source": {
    "excludes": [
      ""
    ]
  }
}

• "size": <RESULT_SIZE>: クライアントに返されたヒット数。このベンチマークでは、Recall@100を計算するために、結果のサイズは100です。
• "k": <NUMBER_OF_CANDIDATES>: 最近傍候補の数。
• "ef_search": <NUMBER_OF_CANDIDATES>: 検査するベクトルの数。
• "oversample_factor": <OVERSAMPLE>: 再スコアリングを行う前に取得される候補ベクトルの数。

Elasticsearch

GET /_search
{
  "query": {
    "knn": {
      "field": "",
      "query_vector": [...],
      "k": ,
      "num_candidates": ,
      "rescore_vector": {
        "oversample": 
      },
      "filter": {
        
      }
    }
  },
  "size": ,
  "_source": {
    "excludes": [
      ""
    ]
  }
}

• "size": <RESULT_SIZE>: クライアントに返されたヒット数。このベンチマークでは、Recall@100を計算するために、結果のサイズは100です。
• "k": <NUMBER_OF_CANDIDATES>: 各シャードから返す最近傍の数。
• "num_candidates": <NUMBER_OF_CANDIDATES>: knn検索を実行する際にシャードごとに考慮する最近傍候補の数。
• "oversample": <OVERSAMPLE>: 再スコアリングを行う前に取得される候補ベクトルの数。

例

Knn クエリ（ 100_500_1 ）は次のようになります。

OpenSearch

GET search_catalog_128/_search
{
  "query": {
    "knn": {
      "search_catalog_embedding": {
        "vector": [...],
        "k": 500,
        "method_parameters": {
          "ef_search": 500
        },
        "rescore": {
          "oversample_factor": 1
        },
        "filter": {
          "term": {
            "valid": true
          }
        }
      }
    }
  },
  "size": 100,
  "_source": {
    "excludes": [
      "search_catalog_embedding"
    ]
  }
}

Elasticsearch

GET search_catalog_128/_search
{
  "query": {
    "knn": {
      "field": "search_catalog_embedding",
      "query_vector": [...],
      "k": 500,
      "num_candidates": 500,
      "rescore_vector": {
        "oversample": 1
      },
      "filter": {
        "term": {
          "valid": true
        }
      }
    }
  },
  "size": 100,
  "_source": {
    "excludes": [
      "search_catalog_embedding"
    ]
  }
}

Terraformスクリプト、Kubernetesマニフェスト、ベンチマークコードとともに、完全な構成はこのリポジトリのes-9.3-vs-os-3.5-vector-searchフォルダで入手可能です。

クラスターの設定

私たちは、16 vCPUと64 GB RAMを備えた6台のe2-standard-16クラウドサーバーでテストを実行しました。各サーバーにおいて、検索エンジンノードを実行する各Kubernetesポッドに15個のvCPUと56GBのRAMを割り当て、そのうち28GBをJVMヒープ用に確保しました。

クラスターはElasticsearch 9.3.0とOpenSearch 3.5.0（Lucene 10.3.2）で実行しました。このベンチマークでは両方のシステムが同じLuceneバージョンを使用しているため、観測されたスループットとレイテンシの違いはLucene単独に起因するものではなく、各エンジンがフィルタリングされたk近傍法（kNN）による検索と再スコアリングをどのように統合し実行するかの違いを反映します。私たちは、3つのプライマリシャードと1つのレプリカ（合計6つのシャード、ノードごとに1つ）を持つ単一のインデックスを使用しました。

我々はまた、同じリージョン内の別のサーバーを使用してベンチマーククライアントを実行し、タイミング統計を収集しました。

データセット

このベンチマークでは、2,000万件のドキュメントを含む大規模なeコマーススタイルのカタログ埋め込みデータセットを使用しました。これは、実世界のフィルタリングされたベクトル検索を大規模なスケールで反映するように設計されています。

各ドキュメントはカタログ項目を表し、以下を含みます。

• 近似kNN検索に使用される128次元の密なベクトル埋め込み。
• 構造化されたメタデータフィールドを使用してフィルタリング（例：アイテムの有効性と可用性、およびその他のカタログ制約）を行うことで、適格なサブセット内でのみ最近傍を取得するという一般的な本番パターンを可能にします。

このデータセットを選んだ理由は、本番環境におけるエージェント型システムやRAG型システムで見られる主要なパフォーマンス上の課題を捉えているからです。つまり、ベクトル類似性だけでは不十分であり、検索はフィルタによって制約されることが多く、システムはこれらの制約の下で高い再現率を維持しながらレイテンシを低く抑える必要があるということです。より小規模なQAスタイルのデータセットと比較すると、2000万件の文書コーパスは、フィルタリングされたANNシステムが実際に直面する規模と候補数によるプレッシャーをより適切に反映しています。

まとめ

現代のAIアーキテクチャー、特にコンテキストエンジニアリングを中心としたアーキテクチャーにおいては、ベクトル探索の速度は些細な実装上の問題ではなく、乗数です。エージェントとワークフローが取得 → 推論 → 取得を繰り返す際、検索パフォーマンスはエンドツーエンドのレイテンシ、スループット、モデルに供給されるコンテキストの品質を直接形作ります。

当社のベンチマークでは、Elasticsearchは、OpenSearchと比べて、より低いレイテンシで一貫して高い再現率を達成しました。これは、類似ベクトルの取得だけでなく、正確性が「適切なドキュメントを取得できること」に左右されるシナリオで顕著でした。制御されたデータセットではその差は明確であり、本番環境では、大量の検索呼び出しを通じてそれらの利点が蓄積され、応答性が向上し、容量余裕が増加し、インフラストラクチャーコストが削減されます。

参考資料

1. コンテキストエンジニアリングとは何ですか？
2. ハイブリッド検索とコンテキストエンジニアリングの進化
3. AIエージェント向けコンテキストエンジニアリングにおける関連性の影響

このファミリーには2つのモデルが含まれます。

• jina-embeddings-v5-text-small
• jina-embeddings-v5-text-nano

これらのモデルは、埋め込みモデルの革新的な新しいトレーニングレシピの成果です。いずれも、同等サイズのモデルよりも何倍も優れたパフォーマンスを発揮し、メモリとコンピューティングリソースを節約し、リクエストへの応答を高速化します。

jina-embeddings-v5-text-smallモデルは6億7700万パラメーターを持ち、32768トークンのインプットコンテキストウィンドウをサポートし、デフォルトで1024次元の埋め込みを生成します。

jina-embeddings-v5-text-nano はその兄弟の約3分の1のサイズで、239Mのパラメーターと8192トークンのインプットコンテキストウィンドウを持ち、スリムな768次元の埋め込みを生成します。

これら2つのモデルは、MMTEB（Multilingual MTEB）ベンチマークの総合的なパフォーマンスにおいてクラス最高です。5億未満のパラメーターを持つモデルの中でjina-embeddings-v5-text-nanoはトップパフォーマーであり、2億5000万未満のパラメータを持ちながらも、7億5000万未満のパラメータを持つ多言語埋め込みモデルの中でjina-embeddings-v5-text-smallモデルがリーダーです。

これらのモデルは、Elastic Inference Service（EIS）やオンラインAPIを介して利用でき、ローカルホスティングでも利用できます。jina-embeddings-v5-textモデルにアクセスする方法については、以下の「はじめに」セクションを参照してください。

埋め込みモデルとセマンティックインデックスにより、検索アルゴリズムの精度が劇的に向上するだけでなく、以下のようなセマンティック類似性や意味抽出を伴うタスクにもさまざまな用途があります。

• 重複したテキストの検索。
• 言い換えや翻訳の認識。
• トピックの発見。
• 推奨エンジン。
• 感情分析と意図分析。
• スパムフィルタリング。
• その他多数。

特徴

この新しいモデルファミリーには、関連性を高め、コストを削減するために設計された多くの特徴があります。

タスクの最適化

私たちは、jina-embeddings-v5-text のモデルを4つの幅広いタスクタイプに最適化しました。

あるタスクを最適化するということは、通常、別のタスクを妥協する必要があることを意味します。そのため、ほとんどの埋め込みモデルは、1種類のタスクに対してのみ競争力のあるパフォーマンスを発揮します。しかし、jina-embeddings-v5-textモデルは、タスク固有のLow-Rank Adaptation（LoRA）アダプターをトレーニングすることで、妥協することなく4つのすべての分野に特化できます。

LoRAアダプターはAIモデルのプラグインの一種であり、全体のサイズをわずかに増やすだけでAIモデルの動作を劇的に変化させます。jina-embeddings-v5-text モデルファミリーでは、タスクごとにモデル全体を用意し、それぞれに何億ものパラメーターを持たせる代わりに、各タスクにコンパクトなLoRaアダプターを備えた1つのモデルだけを使用できます。これによりメモリ、ストレージ容量、推論コストを節約できます。

埋め込みの切り捨て

私たちは、 Matryoshka Representation Learningを使用してjina-embeddings-v5-textモデルをトレーニングしました。これにより、品質への影響を最小限に抑えながら、埋め込みを小さなサイズに削減できます。

デフォルトでは、jina-embeddings-v5-text-small は1024次元の埋め込みベクトルを生成し、各ベクトルは16ビットで表されます。大量のドキュメントコレクションの場合、格納するデータ量が多くなり、埋め込みで満たされたベクトルデータベースでの検索は、データベースのサイズと各格納されたベクトルが持つ次元の数に比例します。

しかし、埋め込みのサイズを半分に減らす（1024次元のうち512次元を切り捨てる）だけで、占有スペースを半分にしながら検索速度を2倍にすることができます。これはパフォーマンスに影響を与えます。情報を捨てると精度が低下しますが、下のグラフが示すように、埋め込みの半分を取り除いてもパフォーマンスはわずかしか低下しません。

埋め込みが少なくとも256次元であれば、精度の損失は比較的小さいはずです。しかし、そのレベルを下回ると、関連性と正確性はすぐに低下します。

このような埋め込みの切り捨てにより、ユーザーは精度と計算コストのバランスを自分で管理できるようになり、検索AIから大きな効率の向上と大幅なコスト削減を実現するツールを提供します。

堅牢な量子化

量子化は埋め込みのサイズを縮小するもう一つの方法です。量子化では、各埋め込みの一部を破棄するのではなく、埋め込み内の数値の精度を下げます。jina-embeddings-v5-text モデルは16ビット数値で埋め込みを生成しますが、これらの数値を四捨五入して精度と格納に必要なビット数を減らすことができます。最も極端な場合では、各数値を1ビット（0または1）に減らすことで、jina-embeddings-v5-textのデフォルトの1024次元の埋め込みを2キロバイトから128バイトに圧縮できます。これは、バイナリ量子化だけで94％の削減になります。切り捨ての場合と同様に、これによりメモリと計算コストが大幅に節約されますが、切り捨てと同様に、量子化によって埋め込みの精度は低下します。

jina-embeddings-v5-textモデルはElasticsearchのBetter Binary Quantizationに対応し、精度の損失を最小限に抑えるようにトレーニングされており、これらのモデルからの二値化埋め込みのベンチマークテストでは、非二値化モデルとほぼ同等の性能を示しています。二値化性能に関する詳細なアブレーション研究についてはテクニカルレポートをご参照ください。

多言語パフォーマンス

多くの埋め込みモデルは、多数の言語を含む素材でトレーニングされているため、多言語対応です。しかし、サポートされているすべての言語で、すべてが同じように優れたパフォーマンスを発揮するわけではありません。

MMTEBの多言語ベンチマークで211の言語を特定し、それらを分離して、言語ごとにモデルを類似のモデルと比較できるようにしました。下の画像は、私たちの結果をヒートマップとしてまとめたものです。各パッチは言語（ISO-639コードで識別）であり、緑色が濃くなるほど、類似モデルの平均と比較してモデルのパフォーマンスが優れていることを示します。

正確さは言語によって異なりますが、jina-embeddings-v5-text モデルは最先端か、世界のほとんどの言語でほぼ最新です。

詳細な多言語パフォーマンスについては、jina-embeddings-v5-textテクニカルレポートを参照してください。

ElasticにおけるJina：最先端のネイティブAIによる検索

jina-embeddings-v5-textモデルをEISで使用することで、Elasticsearchでネイティブに高パフォーマンスの多言語埋め込みモデルを実行できます。これは、完全に管理されたGPUアクセラレーションによる推論で、インフラを提供したりスケールする必要はありません。jina-embeddings-v5-text モデルは、最新のAI開発によって強化されたコンパクトで多言語対応のモデルで、成長するEISモデルカタログを拡張します。これらのモデルは、情報検索と標準データ分析ベンチマークにおいて最先端のパフォーマンスを発揮し、他に類を見ない世界規模の多言語サポートを提供します。

サイズが大きく異なる2つのモデルが用意されているため、ユーザーは用途や予算に応じてどちらが最適かを判断できます。さらに、より小さなサイズに切り詰められたり、より低い精度に量子化されたりしてもパフォーマンスを維持する堅牢な埋め込みにより、jina-embeddings-v5-text モデルはストレージと計算コストおよび処理遅延においてさらなる具体的な節約の機会を提供します。

jina-embeddings-v5-textファミリー、Jina Reranker、Elasticの高速ベクトルおよびBM25検索により、ユーザーはElasticのエンドツーエンドの最先端のハイブリッド検索にアクセスできるようになりました。最も関連性の高い結果が必要な場合、Retrieval-Augmented Generation（RAG）パイプライン、検索アプリケーション、またはデータ分析において、ElasticとJinaの検索AIモデルは、堅固で費用対効果の高い品質を提供します。

はじめに

jina-embeddings-v5-textモデルはEISに完全に統合されており、インデックス作成時にtype フィールドを semantic_textに設定し、inference_idフィールドでモデル（jina-embeddings-v5-text-smallまたはjina-embeddings-v5-text-nano）を指定することで使用できます（次の例を参照）

PUT multilingual-semantic-index
{
  "mappings": {
    "properties": {
      "content": {
        "type": "semantic_text",
        "inference_id": ".jina-embeddings-v5-text-small"
      }
    }
  }
}

# Ingest data about France
POST multilingual-semantic-index/_doc
{
  "content": "The capital of France is Paris"}

GET multilingual-semantic-index/_search
{
  "query": {
    "semantic": {
      "field": "content",
      "query": "What is the French capital?"
    }
  }
}

Elasticsearchはインデキシングおよび検索時に適切なLoRAアダプターを自動的に選択します。埋め込み次元（上記の「埋め込みの切り捨て」セクション参照）は、カスタム推論エンドポイントを作成する際に設定できます。

jina-embeddings-v5-textモデルの利用については Elasticsearchのドキュメントを参照してください。

詳細情報

jina-embeddings-v5-textモデルについて詳しくは、Jina AIブログのリリースノートとテクニカルレポートをお読みください。パフォーマンスとJina AIの革新的な新しいトレーニング手順に関するより詳細な技術情報が記載されています。これらのモデルのローカルダウンロードや運用については、Hugging Faceのjina-embeddings-v5-textコレクションページをご覧ください。

Jina AIモデルは CC-BY-NC-4.0ライセンスの下で利用可能ですので、自由にダウンロードして試すことができますが、商用利用の場合は Elastic Salesまでお問い合わせください。

この記事では、最小スコアパラメータを使用して、セマンティック検索結果の精度を高める方法を学びます。このブログ記事で示された例を試したい場合は関連するJupyterノートブックをご覧ください。

背景：精度と再現率

検索の関連性において、精度と再現率は重要な概念です。まだご存知でない読者の方は、これについて一読されることをおすすめします。以下は要約です。

• 精度：返される検索結果のうち、ユーザーに関連するものの割合。
• 再現率：コーパス内のすべての関連ドキュメントのうち、検索結果セットに含まれるドキュメントの割合。

つまり、言い換えれば、精度とは関連する結果のみを返すことであり、再現率はすべての関連する結果を返すことです。ご想像のとおり、これらは競合する要件であることが多いです。セマンティック検索は再現率が非常に高い傾向がありますが、精度に問題が生じる可能性があります。以下では、この特性について説明します。

最小スコアパラメーターの導入

「min_score」パラメーターを使用すると、最小スコアを設定して精度を向上させることができます。これにより、定義されたしきい値未満のスコアを持つ一致が削除され、結果セットが切り捨てられます。以下は簡単な例です。

GET search-movies/_search
{
  "retriever": {
    "linear": {
      "min_score": 4,
      "retrievers": [
        ...
      ]
    }
  }
}

スコアの正規化

最小スコアを設定するのは良いことですが、すべてのセマンティックモデルが静的しきい値に適したスコアを返すわけではありません。例えば、ELSERは無制限のスコアを返します。一部の高密度モデルのスコアは密集してクラスター化されており、特定のクエリのコンテキストでのみ意味を持ちます。

ほとんどのセマンティック検索では、「min_score」を適用する前に正規化アプローチを使用することをお勧めします。正規化により、ドキュメントのスコアが定義された範囲内に収まるようになります。Elasticsearchレトリバーは、「l2_norm」と「minmax」という2つの正規化機能を提供します。最もよく使用されるのは「minmax」です。これは理解しやすく、多くのシナリオでうまく機能するためです。「minmax」の主な特性は次のとおりです。

• ドキュメントのスコアは0から1の間で配分されます。
• 最も高いスコアを持つドキュメントには常に1のスコアが付けられます。
• 最も低いスコアを持つドキュメントには常に0のスコアが付けられます。
  • これにより、キーワード検索に適さなくなる可能性があります。詳細については「ハイブリッド検索」セクションをご覧ください。

以下は、 min_scoreを使用した正規化されたセマンティッククエリの例です。ランクウィンドウのサイズが500に増え、100から始まるより長い検索結果のリストを返すことができます。

GET search-movies/_search
{
  "size": 100,
  "_source": [
    "title", "overview"
  ],
  "retriever": {
    "linear": {
      "rank_window_size": 500,
      "min_score": 0.25,
      "retrievers": [
        {
          "normalizer": "minmax",
          "retriever": {
            "standard": {
              "query": {
                "semantic": {
                  "field": "overview_vector",
                  "query": "superhero movie"
                }
              }
            }
          }
        }
      ]
    }
  }
}

サイズは、通常の本番環境で見られるサイズよりも高い値に設定されています。これは、検索結果の品質を検査し、結果を調整できるようにするためです。

線形レトリバーを使用したハイブリッド検索

ハイブリッド検索の場合、最も簡単な方法は、すべてのスコアを正規化し、重みを割り当て、最小スコアを適用することです。合計が1になる重みを選択すると、合計スコアが0～1の範囲内に保たれることに注意してください。これにより、最終スコアの理解やmin_scoreのチューニングが容易になります。以下はその例です。

GET search-movies/_search
{
  "size": 100,
  "_source": ["title", "overview","keywords"],
  "retriever": {
    "linear": {
      "rank_window_size": 500,
      "min_score": 0.25,
      "retrievers": [
        {
          "weight": 0.6,
          "normalizer": "minmax",
          "retriever": {
            "standard": {
              "query": {
                "semantic": {
                  "field": "overview_vector",
                  "query": "superhero movie"
                }
              }
            }
          }
        },
        {
          "weight": 0.4,
          "normalizer": "minmax",
          "retriever": {
            "standard": {
              "query": {
                "multi_match": {
                  "query": "superhero movie",
                  "fields": ["overview","keywords", "title"],
                  "type": "cross_fields",
                  "minimum_should_match": "2"
                }
              }
            }
          }
        }
      ]
    }
  }
}

RRFを使用したハイブリッド検索

BM25では、多くの場合、 AND演算子やminimum_should_matchを使用するなど、他の手段で精度を制御します。さらに、単一で、正確で、まれな用語からなるクエリは、自然に検索結果の少ない検索結果を引き起こし、多くの場合、すべてが非常に関連性の高いものです。これにより、次のことが発生する可能性があります。

• 絶対的なBM25スコアが最大スコアのヒットに近い場合でも、結果内のさらに後ろの結果にはBM25レトリバーで低い正規化スコアが割り当てられます。
• 非常に低いBM25スコアをセマンティックスコアに追加すると、合計がセマンティックスコアとして近似されます。
• BM25スコアの寄与が不足すると、ドキュメントがmin_score thresholdによって破棄される可能性があります。

解決策として、BM25とセマンティック結果を組み合わせるために、逆順位融合（RRF）を使用することができます。RRFは、各結果セット内の位置に焦点を当てることで、異なる検索アルゴリズムのスコアを比較するという課題を回避します。この場合、min_scoreはセマンティックレトリバーにのみ適用されます。

GET search-movies/_search
{
  "_source": ["title", "overview","keywords"],
  "retriever": {
    "rrf": {
      "rank_window_size": 500,
      "retrievers": [
        {
          "linear": {
            "rank_window_size": 500,
            "min_score": 0.25,
            "retrievers": [
              {
                "normalizer": "minmax",
                "retriever": {
                  "standard": {
                    "query": {
                      "semantic": {
                        "field": "overview_vector",
                        "query": "superhero movie"
                      }
                    }
                  }
                }
              }
            ]
          }
        },
        {
          "standard": {
            "query": {
              "multi_match": {
                "query": "superhero movie",
                "fields": ["overview", "keywords","title"],
                "type": "cross_fields",
                "minimum_should_match": "2"
              }
            }
          }
        }
      ]
    }
  }
}

まとめ

min_scoreを使用することで、セマンティック検索アルゴリズムの高い再現率によって引き起こされる結果セット内の誤検出の数を減らす方法を示しました。レトリバーの詳細については、こちらのブログ記事とElasticsearchのドキュメントをご覧ください。

Elasticでの依存関係管理

Elasticでは、プライベートとパブリックの両方で、数百、数千ものリポジトリを管理する必要があります。重大なCVEが発見された場合、どのリポジトリが脆弱であるかを即座に回答して対処する必要があります。どれくらい早くパッチを当てられるでしょうか。セキュリティとは別に、生産性に関する質問も出てきます。手動のタスクにあまり時間をかけずに、新しいパッケージバージョンのリリースを、それに依存するすべてのリポジトリに迅速に広めるにはどうすればよいでしょうか。

依存関係管理の方法を探す最初のきっかけは、CVE削減のための自動更新を備えた安全な基盤を確立する必要性でした。依存関係管理に関するソリューションを慎重に検討した後、まずセルフホスト型のインフラストラクチャーの作業を開始しました。私たちは独自のKubernetesクラスターを使用して、Mend Renovate Community Self-Hostedを実行していました。ユーザーがセルフサービスでアクセスできる依存関係管理プラットフォームを提供するというアイデアがありました。

最初の実験が成功したため、より多くのチームが私たちのプラットフォームを導入し、日常のリポジトリのライフサイクルにおける更新やCVEパッチ適用に使用するようになりました。この展開は非常に速く、私たちはすぐにセルフマネージドインストールの限界に達しました。

課題：多数のリポジトリを持つ大規模な組織で依存関係管理プラットフォームを拡張するにはどうすればよいでしょうか。

当社の依存関係管理プラットフォームは、一度に1つのリポジトリを処理しており、シーケンシャルな処理モデルでは、当社の所有する多数のリポジトリに対応できませんでした。依存関係管理ツールの単一のインスタンスで拡大し続けるリポジトリのリストを処理するという概念に問題があることは、すでに認識していました。リポジトリはキュー内に留まり、場合によっては何時間も待機することがありました。リポジトリの50%以上は毎日処理されていませんでした。つまり、当社のリポジトリの50%以上がスキャン間でを24時間以上待っていたということです。

大規模なリポジトリでは、コードベースのサイズが大きく、PRが複数オープンしているため、ボトルネックが大きくなります。GitHub Webhookイベントによりこのシーケンスが中断されました。スキャンのタイミングが予測できないため、Automergeの信頼性が低下しました。スキャンの頻度についてはユーザーと約束していましたが、それを果たすことができませんでした。

社内で構築するという決定：Elastic独自のスケールとセキュリティのニーズに対応

商用オプション、具体的にはMendのRenovate Self-Hosted Enterprise Self-Hosted版も検討しましたが、Elastic社内ではいくつかの主要な取り組みが進行中でした。

社内プラットフォームを構築するという当社の決定は、Elastic の特定の譲れない要件を満たすには、徹底的にカスタマイズされたソリューションしかないという認識に基づいていました。

1. 内部開発者プラットフォームへの投資：当時、私たちはすでに内部開発者プラットフォームに多額の投資を行っていました。それぞれのサービスをこれに適合させる方法について議論し、設計していました。つまり、依存関係管理プラットフォームの独自のルールと実践をテストドライブするというニーズがあり、それに加えて、新しいガイドラインが導入されることになり、イベントに先立ってプラットフォームを設計したいと考えていました。
2. ネイティブ統合とワークフローのカスタマイズ：社内ツールや社内プロセスとの簡単な統合が必要で、例えば、Service Catalog（Backstage）を使用して構成をコードとして一元管理したいと考えていました。Backstageの使用に関しては、特定のニーズがあり、当社のプラットフォームと互換性を持たせたいと考えていました。したがって、Renovate Self-Hosted APIをBackstageの自動化と併用することは可能ですが、これでは当社の内部プロセスを完全にカバーすることはできません。
3. Elastic特有の徹底したセキュリティ対策：当社の厳格なセキュリティコンプライアンスには、当社のエコシステムに合わせた特注のセキュリティメカニズムが必要でした。「非人間的アイデンティティ」の使用の強化に取り組んでいました。このアクセス強化の仕組みにより、GitHub への認証を行う非標準の手段は、この内部実装をサポートしていない市販のツールでは機能しなくなります。当社のワークフローには、親子ワークフローの秘密の暗号化パターンを実装し、一時的な使い捨てのGitHubトークンを使用することが含まれていました。社内で構築することが、これらの独自のセキュリティレイヤーを組み込み、複雑なマルチクラウド環境全体の攻撃対象領域を最小限に抑える唯一の実用的な方法でした。

解決策：依存関係管理のためのワークフローオーケストレーション

解決策の構築は、既に使用している依存関係管理ツールを基に構築し、それを置き換えたり他のソリューションを探したりするのではなく、その上に構築することから始まりました。その可能性の兆しはあり、その柔軟性は組織全体のさまざまなニーズにとって重要です。さまざまなソリューションを検討しましたが、最終的に決め手となったのは、カバーしなければならない大きくて時に特殊なニーズでした。私たちは、各リポジトリが独自に処理され、ボトルネックを解消して成長に備えられる、信頼性が高くスケーラブルな依存関係管理プラットフォームを構築することを決定しました。

プラットフォームは次の3つのコア原則に従って設計しました。

1. 並列処理

各リポジトリに独自の依存関係管理処理環境が与えられます。キューはなくなります。同時実行性は、消費するリソースの数によってのみ制限されます。また、GitHubでレート制限を受けないようにスマートな分散スケジューリングを適用しました。

2．セルフサービス可能

Service Catalog（Backstage）を使用して、新しいリポジトリを自動的にオンボードして管理します。独自のリソース定義を使用して、エンドユーザーにリポジトリの処理頻度を選択するオプション、スケジュールに割り当てるリソースの量、何らかの理由で処理をオンまたはオフにするオプションを提供します。ユーザーのニーズが進化し、新しいインストールに慣れてきたら、そのようにしてさらに多くのオプションを追加していく予定です。

3. シークレットのスコープと名前空間の分離の縮小

セキュリティを強化するために、各ワークフローの開始時に生成される一時的なGitHubトークンを依存関係管理ポッドに提供します。さらに、ワークロードを特定の名前空間に分離して、必要なシークレットのみが提供されるようにします。Kubernetes RBACを使用して、各依存関係管理ワークフローでアクセスできるシークレットを制御します。また、暗号化を使用して、親ワークフローから子ワークフローにGitHubトークンを伝播します。

Kubernetesを使用してプラットフォームを再構築し、Kubernetesのパワーを活用しました。Argo Workflowsはプロセスのロジックを強化し、Renovate CLIはリポジトリを一度に1つずつスキャンして処理するように設定されています。

ここで素晴らしい点は、実績のあるオープンソースプロジェクトを独自の方法で使用し、すべてのプロジェクトに新しい実用的な例を提供すると同時に、開発速度を増幅し、チームのCVE削減を強化していることです。

依存関係管理アーキテクチャー：4つのマイクロサービス

このプラットフォームは、次の4つのカスタムビルドコンポーネントで構成されています。

ワークフローオペレーター（Go/Kubebuilder）

3つのカスタムリソース定義（CRD）を通じてワークフローライフサイクルを管理するKubernetesオペレーター：

• RepoConfig CRD：リポジトリ設定のための信頼できる唯一の情報源。

RepoConfigはオペレーターで次のように定義されています。

// RepoConfig is the Schema for the repoconfigs API
type RepoConfig struct {
	metav1.TypeMeta `json:",inline"`

	// metadata is a standard object metadata
	// +optional
	metav1.ObjectMeta `json:"metadata,omitempty,omitzero"`

	// spec defines the desired state of RepoConfig
	// +required
	Spec RepoConfigSpec `json:"spec"`

	// status defines the observed state of RepoConfig
	// +optional
	Status RepoConfigStatus `json:"status,omitempty,omitzero"`
}

RepoConfigのインスタンスは次のようになります。

apiVersion: workflows.elastic.co/v1
kind: RepoConfig
metadata:
  generation: 3
  name: elastic-test-repo
  namespace: dependency-management-operator
spec:
  owner: group:my-team
  renovate:
    config:
      resourceGroup: SMALL
      runFrequency: 4h
    enabled: true
  repository: elastic/test-repo

• 親CRD：スケジュールされたスキャンのCronWorkflowを管理します。

親コントローラの調整ループ内では、ワークフロー設定が作成され、最新の状態に保たれ、必要に応じて削除されることを確認します。

まず、ワークフローのグローバル設定を取得します。

func (r *ParentReconciler) reconcileSubResources(ctx context.Context, req ctrl.Request, parent *workflowsv1.Parent) error {
	logger := logf.FromContext(ctx)
	logger.Info("Reconcile SubResources for Parent", "name", req.NamespacedName)
	wfSet := workflowsettings.WorkflowSettings{
		RunFrequency:   parent.Spec.RunFrequency,
		ResourceGroups: "parent",
	}

mutexのconfigmapが最新であることを確認し、類似したワークフローが同時に動作しないようにします:

	cfMngr := resources.NewConfigMapManager(r.Client, r.Scheme, r.OperatorConfig.ParentNamespace)
	err := cfMngr.CreateOrUpdateSyncMutexConfigmap(ctx, fmt.Sprintf("%s%s", r.OperatorConfig.ResourcesPrefix, r.OperatorConfig.SyncMutexCfgMapName), strings.TrimPrefix(parent.Spec.Repository, "elastic/"), r.OperatorConfig.SemaphoreConcurrencyLimit)

そして、Cronワークフローとワークフローテンプレートを作成または更新する構造体であるワークフローマネージャーを作成します。

	wfMngr := resources.NewArgoWorkflowManager(r.Client,
		r.Scheme,
		curateResourceName(
			strings.ReplaceAll(parent.Spec.Repository, "/", "-"),
		),
		parent.Namespace,
		"parent-workflow",
		false).
		WithOrganization(r.OperatorConfig.GitHubOrg).
		WithRepoName(parent.Spec.Repository).
		Init(true, true).
		WithPrefix(r.OperatorConfig.ResourcesPrefix).
		WithWfTemplateName(r.OperatorConfig.ParentWorkflowTemplate).
		WithResources(wfSet.GetResourceCategory()).
		WithSchedule(wfSet.GetCronSchedule()).
		WithImagePullSecrets([]corev1.LocalObjectReference{{
			Name: r.OperatorConfig.WorkflowImagePullSecrets,
		}}).
		AddArgument(true, true, "extra_cli_args").
		SetArgument(true, false, "extra_cli_args", "none").
		AddTemplate(resources.NewParentDAGTemplateInstance()).
		AddTemplate(resources.NewWorkflowsTemplateInstance("check-child-workflows", r.OperatorConfig.WorkflowImagePullPolicy, r.OperatorConfig.WorkflowNodeSelector)).
		AddTemplate(resources.NewWorkflowsTemplateInstance("security", r.OperatorConfig.WorkflowImagePullPolicy, r.OperatorConfig.WorkflowNodeSelector)).
		AddTemplate(resources.NewWorkflowsTemplateInstance("submit-child-workflow", r.OperatorConfig.WorkflowImagePullPolicy, r.OperatorConfig.WorkflowNodeSelector))
	wfMngr.OverWriteCommand("submit-child-workflow", r.OperatorConfig.ChildNamespace)
	wfMngr.OverwriteWfTemplateName("parent-wftmpl")
	wfMngr.AddSynchronization(fmt.Sprintf("%s%s", r.OperatorConfig.ResourcesPrefix, r.OperatorConfig.SyncMutexCfgMapName), "{{workflow.parameters.repo_name}}")
	err = wfMngr.CreateOrUpdateCronWorkflow(ctx)
	if err != nil {
		return fmt.Errorf("failed to create or update cron workflow: %w", err)
	}
	err = wfMngr.CreateOrUpdateWorkflowTemplate(ctx)
	if err != nil {
		return fmt.Errorf("failed to create or update workflow template: %w", err)
	}
	return nil

• 子CRD：リポジトリごとのリソースを使用してWorkflowTemplatesを管理します。

子コントローラにーは親と同様の調整義務がありますが、今回は親ワークフローによってトリガーされる子名前空間内のワークフローテンプレートを担当します。

func (r *ChildReconciler) reconcileSubResources(ctx context.Context, req ctrl.Request, child *workflowsv1.Child) error {
	logger := logf.FromContext(ctx)
	logger.Info("Reconcile SubResources for Child", "name", req.NamespacedName)
	wfSet := workflowsettings.WorkflowSettings{
		ResourceGroups: child.Spec.ResourceCategory,
	}
	wfMngr := resources.NewArgoWorkflowManager(r.Client,
		r.Scheme,
		curateResourceName(
			strings.ReplaceAll(child.Spec.Repository, "/", "-"),
		),
		child.Namespace,
		"runner",
		true).
		Init(false, true). // only manage workflow template
		WithPrefix(r.OperatorConfig.ResourcesPrefix).
		WithSuffix("-child-wftmpl").
		WithRepoName(child.Spec.Repository).
		WithOrganization(r.OperatorConfig.GitHubOrg).
		WithResources(wfSet.GetResourceCategory()). // will override resources of presets if set
		WithImagePullSecrets([]corev1.LocalObjectReference{{
			Name: r.OperatorConfig.WorkflowImagePullSecrets,
		}}).
		AddTemplate(resources.NewWorkflowsTemplateInstance("runner", r.OperatorConfig.WorkflowImagePullPolicy, r.OperatorConfig.WorkflowNodeSelector)).
		AddArgument(false, true, "repo_full_name").
		AddArgument(false, true, "repo_name").
		AddArgument(false, true, "encrypted_token").
		AddArgument(false, true, "extra_cli_args")
	wfMngr.OverWriteCommand("runner", r.OperatorConfig.ChildNamespace)
	err := wfMngr.CreateOrUpdateWorkflowTemplate(ctx)
	if err != nil {
		return fmt.Errorf("failed to create or update workflow template: %w", err)
	}
	return nil
}

マルチコントローラーパターンでは明確な分離が実現されます。RepoConfigコントローラーはオンボーディング／オフボーディングを処理し、親コントローラーはスケジュールを管理し、子コントローラーは実行テンプレートを処理します。

GitHuイベントゲートウェイ（Go）

GitHubのwebhookを受信し、署名を検証し、組織／リポジトリでフィルタリングし、Argo Eventsにルーティングするセキュアなwebhookプロキシです。依存関係ダッシュボードのインタラクション、PRイベント、パッケージの更新に対応する10個の異なるセンサーを構築しました。

このゲートウェイは、以下の方法でGitHub Appsとの統合を可能にします。

• セキュリティのため、受信したGitHub webhook署名を検証しています。
• 有効なイベントを、すべての関連ヘッダーと認証とともにArgo Events EventSourceに転送します。
• また、EventSourceにAuthSecretを設定し、これを転送されるリクエストのBearerヘッダーとして提供します。
• ログ、メトリクス、再試行ロジックを提供します。

各GitHubイベントリクエストに対して様々な検証を行います。

以下のHTTP属性が存在することを確認します。

// ValidateRequestMethod checks if the request method is POST.
func ValidateRequestMethod(r *http.Request) error {
	if r.Method != http.MethodPost {
		return fmt.Errorf("method not allowed, only POST is accepted")
	}
	return nil
}

// ValidateRequiredHeaders checks for required GitHub headers.
func ValidateRequiredHeaders(r *http.Request) error {
	eventType := r.Header.Get("X-GitHub-Event")
	deliveryID := r.Header.Get("X-GitHub-Delivery")
	signature := r.Header.Get("X-Hub-Signature-256")
	if eventType == "" || deliveryID == "" || signature == "" {
		return fmt.Errorf("missing required GitHub headers")
	}
	return nil
}

// ValidateUserAgent checks that the User-Agent header starts with GitHub-Hookshot/
func ValidateUserAgent(r *http.Request) error {
	userAgent := r.Header.Get("User-Agent")
	if !strings.HasPrefix(userAgent, "GitHub-Hookshot/") {
		return fmt.Errorf("invalid User-Agent")
	}
	return nil
}

また、各リクエストの署名とその構成も検証します。

// ValidateSignature verifies the GitHub webhook signature.
func ValidateSignature(r *http.Request, secret string) ([]byte, error) {
	payload, err := GitHub.ValidatePayload(r, []byte(secret))
	if err != nil {
		return nil, fmt.Errorf("invalid GitHub signature: %w", err)
	}
	return payload, nil
}

// ValidateAllowedOwner checks if the organization login is in the allowed organizations list.
func ValidateAllowedOwner(payload []byte, allowedGitHubOrganizations []string) (string, error) {
	var orgLogin string
	var payloadMap map[string]any
	if err := json.Unmarshal(payload, &payloadMap); err == nil {
		if orgObj, ok := payloadMap["organization"].(map[string]any); ok {
			if login, ok := orgObj["login"].(string); ok {
				orgLogin = login
			} else if name, ok := orgObj["name"].(string); ok {
				orgLogin = name
			}
		}
	}
	if !slices.Contains(allowedGitHubOrganizations, orgLogin) {
		return orgLogin, fmt.Errorf("organization login not allowed")
	}
	return orgLogin, nil
}

最後に、イベントの種類に基づいてArgo Eventsにルーティングします。

	// Map eventType to Argo `EventSource` path
	var endpoint string
	switch eventType {
	case "push":
		endpoint = "/push"
	case "issues":
		endpoint = "/issues"
	case "pull_request":
		endpoint = "/pull-requests"
	default:
		slog.Info("Ignoring unhandled event type", "event_type", eventType, "delivery_id", deliveryID)
		w.WriteHeader(http.StatusOK)
		_, _ = w.Write([]byte("ok"))
		return
	}
	forwardURL := h.config.ArgoEventSourceForwardURL + endpoint

Argo Events側では、10個のセンサーがArgo Events EventBusで新しいイベントを監視します。

apiVersion: argoproj.io/v1alpha1
kind: Sensor
metadata:
  name: {{ .Values.sensors.packageUpdateOnDefaultBranch.name }}
  namespace: {{ .Release.Namespace }}
spec:
  eventBusName: {{ .Values.eventBus.name }}

次に、スクリプトは各センサーのロジックを適用します。

script: |
          local e = event
          if not e or not e.body or not e.body.repository then
            return false
          end

          -- e.g., "refs/heads/main"
          local ref = e.body.ref
          local default_branch = e.body.repository.default_branch
          if not ref or not default_branch then
            return false
          end

          local expected = "refs/heads/" .. default_branch
          if ref ~= expected then
            return false
          end

        {{- if .Values.sensors.packageUpdateOnDefaultBranch.packageFiles }}
          patterns = { {{- range $i, $f := .Values.sensors.packageUpdateOnDefaultBranch.packageFiles }}{{ if $i }}, {{ end }}"{{ $f }}"{{- end }} }
        {{- end }}

          local function anyMatch(path)
            if type(path) ~= "string" then return false end
            for _, pat in ipairs(patterns) do
              -- match filename at repo root, or anywhere under subdirs
              if path:match(pat) or path:match(".+/" .. pat) then
                return true
              end
            end
            return false
          end

          local function filesContainPackage(paths)
            if type(paths) ~= "table" then return false end
            for _, p in ipairs(paths) do
              if anyMatch(p) then return true end
            end
            return false
          end

          -- Inspect all commits (GitHub includes added/modified/removed lists)
          local commits = e.body.commits
          if type(commits) ~= "table" then
            -- Fallback: some payloads include only head_commit
            commits = {}
            if type(e.body.head_commit) == "table" then
              table.insert(commits, e.body.head_commit)
            end
          end

          for _, c in ipairs(commits) do
            if filesContainPackage(c.added) or filesContainPackage(c.modified) or filesContainPackage(c.removed) then
              return true
            end
          end

          return false

Backstage Syncer（Go）

このプロセスでは、Service Catalog（Backstage）に対してRepository Real Resource Entitiesのポーリングを行い、それらをRepoConfig CRDに変換し、プラットフォームを設定変更と同期させます。変更は3分以内に適用されます。

repoMap := make(map[string]map[string]interface{})
			for i := range entities {
				entity := &entities[i]
				if entity.Spec.Type != "GitHub-repository" {
					continue
				}

				implRaw, err := json.Marshal(entity.Spec.Implementation)
				if err != nil {
					logger.Error("Failed to marshal implementation", "error", err)
					continue
				}

				var implMap map[string]interface{}
				err = json.Unmarshal(implRaw, &implMap)
				if err != nil {
					logger.Error("Failed to unmarshal implementation map", "error", err)
					continue
				}
				var repoName string
				if specMap, ok := implMap["spec"].(map[string]interface{}); ok {
					if repo, ok := specMap["repository"].(string); ok {
						repoName = repo
					}
				}
				if repoName == "" {
					continue
				}

				var workflowsRaw []byte
				if v, ok := implMap["spec"].(map[string]interface{}); ok {
					if r, ok := v["renovate"]; ok {
						workflowsRaw, _ = json.Marshal(r)
					} else {
						workflowsRaw = []byte(`{}`)
					}
				} else {
					workflowsRaw = []byte(`{}`)
				}

				var workflowsWithDefaults schema.WorkflowsMetadata
				err = json.Unmarshal(workflowsRaw, &rworkflowsWithDefaults)
				if err != nil {
					logger.Error("Failed to unmarshal workflows config", "error", err)
					continue
				}

				workflowsMap := map[string]interface{}{
					"enabled":        workflowsWithDefaults.Enabled,
					"require_pr":     workflowsWithDefaults.RequirePr,
					"resource_group": string(workflowsWithDefaults.ResourceGroup),
					"run_frequency":  string(workflowsWithDefaults.RunFrequency),
				}
				repoMap[repoName] = map[string]interface{}{
					"renovate": workflowsMap,
					"owner":    entity.Spec.Owner,
				}
			}
			logger.Info("Fetched GitHub Repository data from Backstage", "repository_count", len(repoMap), "status_code", resp.StatusCode)

最後に、そのデータをRepoConfigインスタンスに書き込みます。

ワークフローベース（混合：JavaScript、Go、Helm）

基盤レイヤーには、Helmチャート、JavaScript設定、暗号化サポート付きのRenovate CLI用のGoラッパー、Alpineパッケージ用のカスタムAPKインデクサーが含まれています。

セルフサービス構成

チームはBackstageを通じてリポジトリを宣言的に設定します。

spec:
  renovate:
    enabled: true
    config:
      resourceGroup: LARGE      # SMALL | MEDIUM | LARGE  
      runFrequency: "0 */4 * * *"  # Every 4 hours

リソースグループはリポジトリサイズに基づいてCPUとメモリを割り当てます。

• SMALL: 500m CPU、1Giメモリ。
• MEDIUM: 1000m CPU、2Giメモリ。
• LARGE: 2000m CPU、4Giメモリ。

構成はバージョン管理され、監査可能で、自動的に適用されます。

親子パターン

実行モデルは親子ワークフローパターンを使用しています。

• 親ワークフロー：スケジュールに従って実行される軽量のCronワークフロー。シークレットを暗号化し、スキャンを実行するかどうかを決定し、子プロセスに構成を渡します。
• 子ワークフロー：Renovate CLIが実行される一時的なポッド。リソースを動的に割り当て、シークレットを単独で復号し、完了後に終了します。

この分離により、セキュリティ（親レベルで暗号化されたシークレット）、リソースの最適化（親は最小限のリソースを使用）、拡張性（子が並行して実行）が提供されます。

結果

パフォーマンスの変化

• 変更前：一度に1つのリポジトリで、一部のリポジトリは、おそらく1日以上、1日あたり1,000回未満のスキャンでも処理されませんでした。
• 変更後：100以上の同時スキャン、通常は8,000件のスキャンと1日あたり最大10,000件の記録スキャン。制限は、当社が費やすリソースの量とGitHubのレート制限の扱い方のみです。

費用対効果

奇妙に聞こえるかもしれませんが、1 日に8,000件のポッドを実行すると、同じ結果を達成するために 1 つの長時間実行ポッドを実行するよりもはるかに安価に同じ結果を得ることができます。

以前の設定では、単一のインスタンスを実行していて、調子が良い日には500～600回のスキャンを実行していました。同時に、異なる種類のリポジトリが同じポッドで実行されることから、最大のものに合わせてポッドのサイズを設定する必要がありました。そのサイズは、現在の8つのCPUと16GBのメモリを搭載する特大モデルよりもはるかに大きくなります。

現在の日次出力を満たすには、単一のポッドなら12日間実行する必要があります。それでは、12日間稼働する単一のポッドのコストを、毎日稼働する8,000個の「MEDIUM」サイズのポッドのコストと比較すると、新しい設計は同じスキャン出力に対してはるかに効率的です。

しかし、ワークロードのデフォルト設定が「SMALL」に設定されていることを考慮に入れましょう。大多数は0.5 CPUと1G RAMで正常に実行されており、規模を増やす変更する必要があるのはごく一部です。ワークロードの60％が「SMALL」で実行され、30％が「MEDIUM」で実行され、10％が「LARGE」で実行されている場合（これが実際に近い値です）に何が起こるかを見てみましょう。

同じ出力に対して、現在の設定ではるかに費用対効果に優れていることがわかります。

強化されたセキュリティ

• 一時的なGitHubトークン（数分間の公開と数日間の公開の比較）。
• ロールベースアクセス制御（RBAC）境界による名前空間の分離。
• 親ワークフロー内の保存時のシークレットの暗号化。
• 直接のVaultアクセスを削除。

予測可能なパフォーマンス

スキャン頻度が保証されれば、最終的にサービスレベル目標（SLO）を設定できます。Automergeは確実に動作します。チームは、プラットフォームが約束どおりの成果をもたらすと信頼しています。

重要なアーキテクチャ上の決定

ここでは、プラットフォームの外観を形作る重要な設計上の決定事項をいくつか紹介します。

• 親子ワークフローが必要な理由

多層防御戦略を実施するためにこのパターンを採用しました。価値の高い認証情報（GitHubアプリのシークレットなど）を専用のロックダウンされた名前空間に制限することで、RBACを使用して、一時的な実行ポッドが機密データに恣意的にアクセスできないようにします。最近のサプライチェーンの脆弱性（例えば、"Shai Hulud"継続的インテグレーション/継続的デリバリー[CI/CD]攻撃）は、動的スクリプトを実行するランタイム環境を認証情報ストアから分離することの重要性を実証しています。

同時に、この分離により、きめ細かなリソースの最適化が可能になります。「親」ワークフローは軽量のオーケストレーターとして機能し、最小限のフットプリントで動作します。一方、「子」ワークフローは計算集約型の依存関係スキャンを処理します。この分離により、各レイヤーに個別の調整ロジックを適用し、スケジューリングとセキュリティインフラ（親）の管理制御を維持しながら、実行パラメータ（子）の制御をユーザーに許可することで、ライフサイクル管理を簡素化できます。

• セルフサービス可能な理由

リポジトリ構成のボトルネックとなる当社のチームを排除することは重要な要件でした。私たちの使命は、多様なユースケースをサポートできるスケーラブルなセルフサービスプラットフォームを設計することでした。リポジトリの膨大な量を考慮すると、すべての構成変更のゲートキーパーとして機能することは持続不可能であると認識しました。代わりに、私たちは「レール」（インフラストラクチャとガードレール）を提供しながら、ユーザーが「列車」（実行とカスタマイズ）を運転できるようにするという支援の哲学を採用しました。こうしたチームの自律性へのシフトが、ユーザーがシステムをそれぞれの具体的な業務ニーズに合わせてカスタマイズできるようにすることで、生産性を大幅に向上させると信じています。

• Kubernetes Operatorパターンを選択した理由

上記で述べたように、基本的な設計原則は、プラットフォームが完全にセルフサービス可能であることを確保することでした。ユーザーの意図（スキャンの切り替え、スケジューリング頻度の調整、ランタイムリソース制限の調整など）を捉え、それらの変更を基盤となるワークフローに瞬時に反映する自動化されたメカニズムが必要でした。将来の要件を予測し、システムは簡単に拡張可能である必要もありました。

これを実現するために、カスタムの依存関係管理Kubernetes Operatorを開発しました。設定のインターフェースとしてCRDを使用することで、Kubernetesネイティブな調整ループを確立しました。このオペレーターは、ユーザーが定義した望ましい状態を継続的に監視し、ワークフローインフラに必要な更新を自動的に管理します。これにより、イベント駆動型のシームレスな操作が保証され、プラットフォームのロジックが裏側ですべての複雑さを処理します。

• GitHubイベントゲートウェイを設計する理由

プラットフォームの応答性を高めるために、イベントドリブンアーキテクチャー（EDA）の採用が不可欠でした。CronWorkflowsは信頼性の高いベースラインスケジュールを提供しましたが、ユーザーがダッシュボードから手動でスキャンをトリガーするなどアドホック実行を処理できる俊敏性が必要でした。これを達成するために、ペイロードの整合性を検証し、リクエストをインテリジェントにルーティングするための専用のインジェストゲートウェイが必要でした。

既存のソリューション、特にArgoのネイティブGitHub EventSourceを評価しましたが、 運用上のオーバーヘッドや厳格な GitHub APIクォータ（例：リポジトリごとのwebhook制限）に関する重大なリスクを特定しました。結果として、これらの制限からインフラを切り離すためにカスタムゲートウェイを構築しました。

重要なのは、このゲートウェイが移行中に戦略的なトラフィック制御ポイントとして機能したことです。これはスイッチとして機能し、レガシーシステムから新しいインフラストラクチャへの段階的かつ詳細なロールアウト（トラフィックの移行）を実行できるようになりました。これにより、数千のリポジトリのオンボーディングが「ビッグバン」的な切り替えではなく、制御されたリスクのないプロセスになることが保証されました。

教訓

私たちが学んだいくつかの教訓は Elasticソースコードと密接に関連しています。

1. 顧客第一：プラットフォームはユーザーのために構築されます。したがって、ユーザーのニーズを最優先にすることが重要です。これにより、プラットフォームは、ユーザーとの摩擦を減らし、プラットフォームの拡張を簡素化し、導入を容易にする、効率的に設計されたインフラストラクチャとアプリケーションに形作られます。
2. 空間と時間：時には、最も抵抗の少ない道が不安定な状況につながることがあります。当初、既存の順次処理モデルを最適化しようとしましたが、問題は解決されず、むしろ複雑さが増し、未解決の問題が増えただけでした。プラットフォームを並列処理で再構築するという大胆な決定には、多大な事前開発が必要でしたが、最終的には持続可能なプラットフォームの成長への道を切り開き、日々の面倒な管理業務を事実上排除しました。
3. ITと依存関係：プラットフォームは単独では動作できません。その成功は、より広範なエコシステムとどれだけうまく統合できるかによって決まります。当社の場合、シームレスなサービスオンボーディングのための信頼できる情報源となるため、Backstageとの統合は極めて重要でした。同様に、Artifactoryに接続することで、プライベートパッケージの更新を効率的に管理できるようになります。他にも重要な統合は多々あります。
4. 進歩、シンプルな完璧さ：実装全体を通じて、当初の想定を継続的にプレッシャーテストし、新たな障壁が出現するたびにそれに適応しました。完璧主義に陥るのではなく、反復的なアプローチを採用し、課題に一つずつ取り組み、実際の状況に合わせて移行戦略を調整しました。

次のステップ

このプラットフォームの提供により、プラットフォームのUXと効率性の向上に役立つ、より有意義な作業が可能になります。いくつかの例を以下に示します。

• 自動マージの採用を増やし、ガードレールを設定

自動マージ機能により、面倒な手動タスクが排除され、チームの速度が大幅に向上します。しかし、この速度の向上が安全性を犠牲にすることのないよう、厳格なガードレールを確実に設置する必要があります。

• エンドユーザーエクスペリエンスに関するオブザーバビリティの向上

私たちのロードマップにおける重要な優先事項は、プラットフォームレベルだけでなく、特にエンドユーザーの視点からオブザーバビリティを高めることです。インフラの指標を捉えるのは簡単ですが、実際のユーザー体験を理解するにはより深い洞察が必要です。コアユーザー中心の重要業績評価指標（KPI）を定義し、テレメトリがエスカレートする前の摩擦点やパフォーマンスの問題を検出できるように取り組んでいます。

• より広範な採用を促進するための障壁の除去

将来を見据えた当社の優先事項は、プラットフォームの採用を妨げている障壁を特定して取り除くことです。新しい統合の開発や特定の機能セットの展開が必要な場合でも、当社はデータ主導の計画に取り組んでいます。当社は拡張性を重視したプラットフォームの構築に成功しました。今後は、その潜在能力を最大限に引き出すことに注力していきます。

全体像

依存関係管理ワークフロープロジェクトは、より広範な原則を示しています。つまり、デフォルトの導入モデルを超えてオープンソースツールをスケールする必要がある場合、Kubernetesネイティブパターンが前進する道を提供するということです。

以下を取り入れることで、

• 構成用のCRD
• ライフサイクル管理のためのオペレーター
• 応答性を高めるイベント駆動型アーキテクチャ
• 導入用のGitOps

管理するリポジトリの数に関係なく拡張できるオーケストレーションを構築しました。1つのリポジトリをスキャンするパフォーマンスは、管理するリポジトリが100個でも1,000個でも同じです。

重要なCVEが発表されても、数時間ではなく数分で回答が得られます。それがボトルネックと競争優位の違いです。

謝辞

このプラットフォームは優れたオープンソースツールを基盤としています。

• Kubebuilder：ワークフローをブートストラップして管理するKubernetes Operatorを起動するために使用したオープンソースフレームワーク。[1][2]
• Backstage：Service Catalogを構築し、信頼できる情報源として使用するオープンソースフレームワーク。[1][2]
• Argo WorkflowsとArgo Events：複雑なプロセスを調整し、イベントに基づいて動的な処理を追加するために使用したオープンソーススイート。[1][2][3][4]
• Renovate CLI：リポジトリを処理するオープンソースの依存関係管理ツール。[1][2]

* AWS Fargateの料金モデルを単一ポッドのコストの基準として使用しました。ただし、当社のワークロードは必ずしもAWSで実行されているわけではなく、本格的なKubernetesクラスターで実行されています。

同時実行性の高いワークロード向けにElasticsearchをチューニングする場合の標準的なアプローチは、RAMを最大化してドキュメントのワーキングセットをメモリに保持し、検索レイテンシを低くすることです。結果として、best_compressionは検索ワークロードにはほとんど考慮されません。これは主に、ストレージ効率が優先されるElastic ObservabilityおよびElastic Securityのユースケースでのストレージ節約対策として見なされているためです。

このブログでは、データセットのサイズがOSページキャッシュを大幅に超える場合、best_compressionがI/Oボトルネックを軽減することで検索パフォーマンスとリソース効率を向上させることを示します。

セットアップ

ユースケースは、Elastic CloudのCPUに最適化されたインスタンス上で実行される高同時性検索アプリケーションです。

• データ量：ドキュメント約5億件
• インフラ：6つのElastic Cloud（Elasticsearch Service）インスタンス（各インスタンス：1.76 TBのストレージ | 60 GB RAM | 31.9 vCPU）
• メモリとストレージの比率：総データセットの約5％がRAMに収まる

課題：高いレイテンシ

19:00頃に現在のリクエスト数が急増すると、検索のレイテンシが大幅に悪化することが確認されました。図1と図2に示すように、Elasticsearchインスタンスあたりのトラフィックはピーク時で毎分400リクエスト程度でしたが、平均クエリサービス時間は60ミリ秒以上に低下しました。

初期の接続処理後、CPU使用率は比較的低いままであり、コンピューティングがボトルネックではなかったことを示しています。

クエリボリュームとページフォールトの間の強い相関関係が明らかになりました。リクエストが増加するにつれて、ページフォールトも比例して増加し、ピークは約40万件/分に達しました。これは、アクティブなデータセットがページキャッシュに収まらなかったことを示しています。

同時に、JVMヒープの使用量は正常かつ健全であるように見えました。これにより、ガベージコレクションの問題が排除され、ボトルネックが I/O であることが確認されました。

診断：I/Oバウンド

システムはI/Oバウンド状態でした。Elasticsearchは、メモリからインデックスデータを提供するためにOSページキャッシュに依存します。インデックスがキャッシュに対して大きすぎる場合、クエリによってコストのかかるディスク読み取りがトリガーされます。一般的な解決策は水平方向に拡張すること（ノード/RAMの追加）ですが、まずは既存のリソースの効率改善を最大限に図りたいと考えました。

修正

デフォルトでは、ElasticsearchはインデックスセグメントにLZ4圧縮を使用し、速度とサイズのバランスをとります。best_compression （zstdを使用）に切り替えるとインデックスのサイズが小さくなるという仮説を立てました。フットプリントが小さいほど、ページキャッシュに収まるインデックスの割合が大きくなり、CPUのわずかな増加（解凍用）と引き換えにディスクI/Oが削減されます。

best_compressionを有効にするために、インデックス設定index.codec: best_compressionでデータを再インデックスしました。あるいは、インデックスを閉じ、インデックスコーデックをbest_compressionにリセットしてから、セグメントのマージを実行することで、同じ結果を得ることができます。

POST my-index/_close
PUT my-index/_settings
{
    "codec": "best_compression"
}
  
POST my-index/_open  
POST my-index/_forcemerge?max_num_segments=1

結果

結果は、ストレージ効率の向上は、CPU使用率の増加を伴わずに検索パフォーマンスの大幅な向上に直接つながるという私たちの仮説を裏付けました。

best_compressionを適用するとインデックスの大きさは約25％減少しました。反復ログデータで確認された削減よりは少ないものの、この25%の削減により、ページキャッシュ容量が同じだけ実質的に増加しました。

次のロードテスト（17:00から）では、トラフィックはさらに増加し、Elasticsearchノードあたり1分あたり500リクエストでピークに達しました。

負荷が高まったにもかかわらず、CPU使用率は前回の実行時よりも低くなりました。前のテストで使用率が高かったのは、過剰なページフォールト処理とディスクI/O管理のオーバーヘッドが原因である可能性があります。

重要なのは、ページフォールトが大幅に減少したことです。ベースラインテストの30万件超に比較して、より高いスループットでもフォールトは1 分あたり20万件未満に留まりました。

ページフォールトの結果はまだ最適とは言えませんでしたが、クエリサービス時間は約50％削減され、負荷が高まった場合でも30ミリ秒未満に留まりました。

結論：検索にはbest_compressionを

データ量が利用可能な物理メモリを超える検索ユースケースでは、 best_compressionは強力なパフォーマンス調整手段となります。

キャッシュミスに対する従来の解決策はスケールアウトしてRAMを増やすことですが、インデックスのフットプリントを削減することで、ページ キャッシュ内のドキュメント数を最大化するという同じ目標を達成しました。次のステップは、インデックスの並べ替えを探求し、ストレージをさらに最適化し、既存のリソースからさらにパフォーマンスを引き出すことです。

エージェントは、効率性の向上と顧客体験の向上をもたらす可能性で注目を集めています。しかし実際には、乱雑で構造化されていないエンタープライズデータを扱う場合など、エージェントに適切なコンテキストを提供することは困難です。開発者は、ツール、プロンプト、状態、推論ロジック、モデルを管理し、ビジネスソースから関連するコンテキストを取得して正確な結果とアクションを提供する必要があります。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、セルフマネージドのエンタープライズティアでご利用いただけます。

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

ガラスを砕く方法の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は、音声パイプラインに複数のレベルで統合できます。

1. Agent Builderツールのみ：音声テキスト変換 → LLM（Agent Builderツール使用）→ テキスト読み上げ
2. MCPとしてのAgent Builder：音声テキスト変換 → LLM（MCP 経由でAgent Builderにアクセス）→ テキスト読み上げ
3. 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による注文を取得するために使用されるツールです。

type: "ES|QL"
toolId: order.search
description: Use this tool to retrieve an order by its ID.
query: |
  FROM orders
    METADATA _score
  | WHERE order_id == ?order_id
  | SORT _score DESC
  | LIMIT 1

parameters:
  order_id: "the ID of the order"

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

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

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

はじめに

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

私たちは皆、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つの問題がありました。

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

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

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

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

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

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

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: "Called tool, with execution id: {{ execution.id }}. Use this ID to poll the results."

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

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

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

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

すべてを集約

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

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

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

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

シナリオ1：DevOpsの救出

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

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

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

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

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

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

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

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

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

はじめましょう

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

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

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

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

これが重要である理由

ほとんどの典型的な分析ワークフローは最終的にデータのグループ化に集約されます。ホストあたりの平均バイト数の計算、ユーザーごとのイベントのカウント、または次元全体でのメトリクスの集計など、コアとなる操作は同じです。キーをグループにマップし、実行中の集計を更新します。

小規模であれば、ほぼすべての適切なハッシュテーブルで問題なく動作します。大規模になると（数億のドキュメントと数百万の個別のグループなど）、詳細が重要になってきます。負荷係数、プローブ戦略、メモリレイアウト、キャッシュの動作によって、線形パフォーマンスとキャッシュミスの連続との間に違いが生じる可能性があります。

Elasticsearchは長年にわたってこれらのワークロードをサポートしてきましたが、コアアルゴリズムを最新化する機会を常に探しています。そのため、スイステーブルからヒントを得た新しいアプローチを評価し、それをES|QLが統計を計算する方法に適用しました。

スイステーブルとは？

スイステーブルは、GoogleのSwissTableによって普及し、後にAbseilやその他のライブラリに採用された最新のハッシュテーブルファミリーです。

従来のハッシュテーブルでは、ポインターの追跡やキーのロードに多くの時間を費やし、結局一致しないことが判明します。スイステーブルの特徴は、キーと値とは別に保存される制御バイトと呼ばれる小さなキャッシュ常駐配列構造を使用してほとんどのプローブを拒否し、メモリトラフィックを大幅に削減できることです。

各制御バイトは単一のスロットを表し、この場合、スロットが空かどうかと、ハッシュから導出された短いフィンガープリントの2つの項目をエンコードします。これらの制御バイトはメモリ上に連続的に配置され、通常16個のグループで構成されており、単一命令多重データ（SIMD）処理に理想的です。

スイステーブルは、一度に1つのスロットをプローブする代わりに、ベクトル命令を使用して制御バイトブロック全体をスキャンします。1回の操作で、CPUは入力キーのフィンガープリントを16個のスロットと比較し、空のエントリーを除外します。この高速パスを通過する少数の候補のみが、実際のキーのロードとの比較を必要とします。

この設計では、少量の追加メタデータと引き換えに、はるかに優れたキャッシュローカリティと大幅に少ないランダムロードを実現しています。テーブルが拡大し、プローブチェーンが長くなるにつれて、それらのプロパティはますます価値が高くなります。

中央にSIMDがあります

ここでの真の主役はSIMDです。

制御バイトは単にコンパクトであるだけでなく、ベクトル命令で処理されるように明示的に設計されています。1 回のSIMD比較で16個のフィンガープリントを一度にチェックできるため、通常はループとなる処理が複数の広範な操作に変わります。例：

実際には、これは次のことを意味します。

• ブランチ数の低減。
• プローブチェーンの短縮。
• キーメモリや値メモリからのロードの減少。
• CPU実行ユニットの利用率が大幅に向上。

ほとんどの検索は制御バイトのスキャンを通過することはありません。そうすれば、残りの作業は焦点が絞られ、予測可能になります。これはまさに、最新のCPUが得意とする種類のワークロードです。

SIMDの仕組み

仕組みを知りたい読者のために、テーブルに新しいキーを挿入すると何が起こるかを説明します。128ビットベクトルのPanama Vector APIを使用し、16の制御バイトを並列で処理します。

次のスニペットは、Intel Rocket LakeとAVX-512で生成されたコードを示しています。手順はその環境を反映していますが、設計はAVX-512に依存しません。同じ高レベルのベクトル操作が、同等の命令（AVX2、SSE、NEONなど）を使用して他のプラットフォームでも実行されます。

; Load 16 control bytes from the control block
vmovdqu xmm0, XMMWORD PTR [r9+r10*1+0x10]

; Broadcast the 7-bit fingerprint of the new key across the vector
vpbroadcastb xmm1, r11d

; Compare all 16 control bytes to the new fingerprint
vpcmpeqb k7, xmm0, xmm1
kmovq rbx, k7

; Check if any matches were found
test rbx, rbx
jne 

各命令は挿入プロセスにおいて明確な役割を果たします。

• vmovdqu：128ビットの xmm0レジスタに16個の連続制御バイトを読み込みます。
• vpbroadcastb：新しいキーの7ビットのフィンガープリントをxmm1レジスタのすべてのレーンにわたって複製します。
• vpcmpeqb: 各制御バイトをブロードキャストされたフィンガープリントと比較し、一致する可能性のあるマスクを生成します。
• kmovq + test：マスクを汎用レジスタに移動し、一致が存在するかどうかをすばやく確認します。

最終的に、ベンチマークにより、レジスタの幅を広げて32バイトまたは64バイトに拡張しても測定可能なパフォーマンス上の利点が得られないことが示されたため、一度に16個の制御バイトのグループをプローブすることに決定しました。

ES|QLにおける統合

Elasticsearchでのスイススタイルのハッシュの採用は、単なる置き換えではありませんでした。ES|QLには、メモリアカウンティング、安全性、コンピューティングエンジンの他の部分との統合に関して厳しい要件があります。

新しいハッシュテーブルを、ページリサイクラーやサーキットブレーカーアカウンティングなどのElasticsearchのメモリ管理と緊密に統合し、割り当てが常に可視かつ制限された状態になるようにしました。Elasticsearchのアグリゲーションは密に格納され、グループIDでインデックス化されるため、メモリレイアウトはコンパクトで高速に保たれ、反復処理も高速になります。また、ランダムアクセスを許可することで特定のパフォーマンスを最適化できます。

可変長バイトキーの場合、グループIDと一緒に完全なハッシュをキャッシュします。これにより、プローブ中に高価なハッシュコードを再計算する必要がなくなり、関連するメタデータを近くに保持することでキャッシュの局所性が向上します。再ハッシュ中は、値自体を検査せずにキャッシュされたハッシュと制御バイトに依存できるため、サイズ変更のコストが低く抑えられます。

実装における重要な簡素化の一つは、エントリーが決して削除されないことです。これにより、トゥームストーン（以前占有されていたスロットを識別するためのマーカー）の必要性がなくなり、空のスロットは実際に空のままになるので、プローブの動作がさらに改善され、制御バイトスキャンが効率的に維持されます。

その結果、スイステーブルの魅力となるパフォーマンス特性を維持しながら、Elasticsearchの実行モデルに自然に適合する設計が実現しました。

パフォーマンス

カーディナリティが小さい場合、スイステーブルのパフォーマンスは既存の実装とほぼ同等になります。これは予想どおりです。テーブルが小さい場合、キャッシュの影響は少なくなり、最適化するための調査もほとんど行われません。

カーディナリティが増加するにつれて、状況は急速に変化します。

上記のヒートマップは、異なるキーサイズ（8、32、64、128バイト）に対する時間改善係数を、1,000から10,000,000グループまでの基数にわたってプロットしています。カーディナリティが増加するにつれて、改善係数は着実に増加し、均一分布の場合は2～3倍に達します。

この傾向はまさに設計が予測していることです。カーディナリティが高くなると、従来のハッシュテーブルではプローブチェーンが長くなりますが、スイススタイルのプローブでは、SIMD対応の制御バイトブロック内でほとんどの検索が引き続き解決されます。

キャッシュの挙動が物語るもの

速度の向上をよりよく理解するために、同じJMH benchmarks をLinuxperf で実行し、キャッシュとTLBの統計を取得しました。

元の実装と比較すると、スイスバージョンでは全体的にキャッシュ参照が約60%少なくなります。最終レベルのキャッシュのロードは4倍以上減少し、LLCロードミスは6倍以上減少します。LLCのミスはメインメモリアクセスに直接変換されることが多いので、この減少だけでエンドツーエンドの改善の大部分を説明できます。

CPUに近いほどL1データキャッシュミスが少なくなり、データTLBミスが約6倍少なくなります。これは、空間的局所性が高く、メモリアクセスパターンがより予測可能であることを示しています。

これがSIMD対応の制御バイトの実用的なメリットです。散在したメモリ位置からキーと値を繰り返しロードする代わりに、ほとんどのプローブは、コンパクトなキャッシュ常駐構造をスキャンすることによって解決されます。アクセスされるメモリが少なければミスも減り、ミスが少なければクエリも速くなります。

まとめ

スイススタイルのハッシュテーブル設計を採用し、SIMDフレンドリーなプロービングを積極的に活用することで、高カーディナリティのES|QL統計ワークロードで2〜3倍の速度向上を達成し、より安定的で予測可能なパフォーマンスを実現しました。

この研究は、現代のCPUに対応したデータ構造が、ハッシュテーブルのような十分に確立された問題においても、大きな性能向上を実現できることを示しています。ここでは、追加のプリミティブ型の特殊化や、結合などの他の高カーディナリティパスでの使用など、さらに検討する余地がありますが、これらはすべて、Elasticsearchの内部を継続的に近代化するための広範かつ継続的な取り組みの一部に過ぎません。

詳細に興味がある方や作業をフォローしたい方は、GitHubのプルリクエストとメタイシューの進捗追跡をチェックしてみてください。

ハッシュを活用しましょう！

結局のところ、コンテキスト内のすべてが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のようなパッシブデータストアを、出力を接地してエージェントを最新の状態に保つことができるアクティブリコールメカニズムに変えます。

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

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

AWSで稼働するすべてのElastic Cloud Serverlessプロジェクトに対して、主要なインフラのアップグレードを完了し、より新しく高速なハードウェアへの移行を行いました。この変更は、すべてのサーバーレスプロジェクトに自動的に適用されました。AWS上のElasticsearch、Elastic Observability、Elastic Securityのサーバーレスプロジェクトにおいて、より高いスループットと低いレイテンシを実現します。

開発者にとっての主なパフォーマンス上のメリット

新しいAWSハードウェアインフラは、Elastic Cloud Serverlessで行われるすべての作業の基盤となり、アプリケーションの速度と応答性に目に見えるメリットをもたらします。

クエリのレイテンシの短縮…スループットの向上

ハードウェアの改良によりコンピューティングリソースの速度が劇的に向上し、検索クエリがこれまで以上に高速に処理されるようになります。

• 検索とベクトル検索：従来の全文クエリを実行している場合でも、最先端のベクトル検索を使用して生成AIと検索拡張生成（RAG）アプリケーションを実行している場合でも、レイテンシが大幅に減少します。内部ベンチマーキングでは、検索レイテンシが平均35%減少したことが示されました。
• より高速なインデキシング：データのインジェスト速度が最適化されているため、膨大なデータ量や複雑なドキュメントのインデキシングがスループット向上とともに可能になります。これは、ほぼリアルタイムのデータ可視性を必要とするアプリケーションにとって非常に重要です。内部ベンチマークではインデキシングスループットの平均26%増加が示されました。

負荷下でも安定したパフォーマンス

Elastic Cloud Serverlessは、ワークロードに関係なく、需要に合わせてリアルタイムで動的に自動スケーリングし、レイテンシを最小限に抑えるように設計されています。このハードウェアのアップグレードにより、スケーリングのパフォーマンスと応答性が向上しました。

• スパイクを容易に処理：ユーザートラフィックの突然の急増や大量のバッチデータ取り込みに直面している場合でも、新しいインフラにより、検索とインデキシングのリソースがより効率的にスケールアップし、一貫して低いレイテンシが維持されます。
• 最適化されたコンピューティングとストレージの分離：サーバーレスアーキテクチャはコンピューティングとストレージを分離し、ワークロードを個別にスケールして、最適なパフォーマンスとコスト効率を実現します。より高速なハードウェアによりコンピューティング層が強化され、この分離設計の効率が最大化されます。

舞台裏：内部のベンチマーク結果

AWSインフラのアップグレードの影響を定量化するため、Elasticのエンジニアリングチームは、さまざまなサーバーレスワークロードに対して包括的な社内ベンチマークを実施しました。これらのワークロードは、ユースケースに関係なく、アプリケーション全体で期待できるパフォーマンスの改善に関する実証的な証拠を提供しました。

ベンチマーキングのアプローチ

私たちは、開発者エクスペリエンスとアプリケーションの応答性に直接影響する主要なメトリクス、応答時間（つまり、レイテンシ）と検索およびインデキシング操作のスループットにテストを集中させました。

• テスト対象のワークロード：テストには、ユーザー向けアプリケーションに典型的な高同時検索操作、複雑なベクトル検索クエリ、オブザーバビリティとセキュリティのユースケースのための大量データのインジェスト/インデキシングが含まれていました。特に、私たちのテスト手法では、ElasticのベンチマーキングツールであるRallyの公開データセットを使用しました。
  • wikipedia: 汎用テキスト検索のパフォーマンスを測定するためにWikipediaのテキストコンテンツのスナップショットから生成されたデータセット。
  • MSMARCO-Passage-Ranking：低密度ベクトルフィールドの検索パフォーマンスを測定するためのMicrosoftのMachine Reading Comprehension (MS MARCO) から派生したデータセット。
  • OpenAI_Vector：高密度ベクトルフィールドの検索パフォーマンスを測定するための、BEIRのNQから派生し、OpenAIのtext-embedding-ada-002モデルによって生成された埋め込みで強化されたデータセット。
• 測定：旧インフラと新インフラのパフォーマンスを比較し、最悪ケースのテールレイテンシを99パーセンタイル（P99）で測定し、操作回数を1秒あたりで計測しました。結果の一貫性を確保するために、各トラックはハードウェアプロファイルごとに5回実行されました。
• 目標：私たちの目的は、インフラストラクチャーが、急速な自動スケーリングの期間中でも、一貫してより速く、より予測可能なパフォーマンスを提供する能力を検証することでした。

パフォーマンスデータの概要

結果では、効率と速度が大幅に向上したことが確認されました。これらの利点は、ユーザーの応答時間の短縮や、より少ないコンピュートリソースで同じ量の作業を完了できることによる運用コストの削減に直結します。

以下の表は、定量的な改善点の詳細です。スループット値は高いほど好ましく、レイテンシは値が低いほど好ましいです。

検索ベンチマーク結果：

インデキシングベンチマークの結果：

追加のボーナス：コスト削減

私たちは低レイテンシのパフォーマンスを提供することに重点を置いていますが、新しいハードウェアの効率性もElasticsearchプロジェクトのコストに直接的なプラスの影響を与えます。

Elasticsearch Serverlessの価格設定は使用量ベースで、消費した取り込みと検索リソースに対してのみ料金が発生します。新しく高速なハードウェアはより効率的であるため、ワークロードはより少ないリソースを使用してタスクを完了することが多くなり、ほとんどのプロジェクトで本質的なコスト削減につながります。高額な費用をかけずに、最高のパフォーマンス向上を実現できます。まさに効率の最適化です。

開発者にとっての意義

このインフラストラクチャーのアップグレードはElasticによって完全に管理されるため、移行や構成の変更を行う必要はありません。改善は、AWSベースのすべてのサーバーレスプロジェクトで即座かつ自動的に行われます。

このアップグレードにより、次のことが可能になります。

• より高速なアプリケーションを構築：基盤となる検索プラットフォームがユーザーが求める速度を提供していることを認識しながら、機能の速度に重点を置けます。
• 自信を持ってイノベーションを実現：プラットフォームが最高のパフォーマンスで負荷を処理できることを保証しながら、ベクトル検索や関連性ランキングなどの複雑なAI機能を含む新しい検索、オブザーバビリティ、セキュリティの機能をデプロイします。
• スタックを簡素化：インフラ管理、容量計画、スケーリングを処理する完全に管理されたサービスを使用することで、コードとデータに集中できます。
  

Jinaモデルは、情報処理、整理、検索をサポートするように設計された大きく3つのカテゴリーに分類されます。

• セマンティック埋め込みモデル
• リランキングモデル
• 小規模な生成言語モデル

セマンティック埋め込みモデル

セマンティック埋め込みの背後にある考え方は、AIモデルがインプットの意味的側面を高次元空間の幾何学の観点から表現することを学習できるというものです。

セマンティック埋め込みは、高次元空間内の点（技術的にはベクトル）と考えることができます。埋め込みモデルは、ニューラルネットワークの一種で、デジタルデータ（テキストや画像など、あらゆるものが入力となりえますが、最も一般的なのはテキストや画像）を入力として受け取り、対応する高次元点の位置を一連の数値座標として出力します。モデルが適切に機能している場合、2つのセマンティック埋め込み間の距離は、対応するデジタルオブジェクトがどの程度同じ意味を持つかに比例します。

これが検索アプリケーションにとっていかに重要であるかを理解するには、「dog」という単語の埋め込みと「cat」という単語の埋め込みを空間上の点として想像してみましょう。

優れた埋め込みモデルは、「feline」という単語に対して「dog」よりも「cat」にずっと近い埋め込みを生成し、「canine」は「cat」よりも「dog」にずっと近い埋め込みを生成するはずです。なぜなら、これらの単語はほぼ同じ意味だからです。

モデルが多言語対応であれば、「cat」と「dog」の翻訳でも同じ結果が期待できます。

埋め込みモデルは、物事間の意味の類似性や不一致を埋め込み間の空間的関係に翻訳します。上の図は2次元のみであるため、画面上で確認できますが、埋め込みモデルでは数十から数千の次元のベクトルが生成されます。これにより、数千語以上を含む文書に対して、何百または何千もの次元を持つ空間上の点を割り当てることで、全体のテキストの意味の微妙なニュアンスをエンコードすることが可能になります。

マルチモーダル埋め込み

マルチモーダルモデルは、セマンティック埋め込みの概念をテキスト以外のもの、特に画像にも拡張します。画像の埋め込みは、その画像の忠実な記述の埋め込みに近いものとなることが期待されます。

セマンティック埋め込みには多くの用途があります。とりわけ、効率的な分類器の構築、データのクラスタリング、データの重複排除やデータの多様性の調査などのさまざまなタスクの実行に使用できます。いずれも、手作業では管理できないほど大量のデータを扱うビッグデータアプリケーションにとって重要です。

埋め込みの最大の直接的な利用は情報検索です。Elasticsearchでは、埋め込みを含む検索オブジェクトをキーとして格納できます。クエリは埋め込みベクトルに変換され、検索によって埋め込みに最も近いキーを持つ格納オブジェクトが返されます。

従来のベクトルベースの検索（低密度ベクトル検索とも呼称）が、ドキュメントやクエリの単語やメタデータに基づくベクトルを使用するのに対し、埋め込みベースの検索（高密度ベクトル検索とも呼称）は、単語ではなくAIによって評価された意味を使用します。これにより、一般に従来の検索方法よりもはるかに柔軟かつ正確になります。

マトリョーシカ表現学習

埋め込みの次元数や数値の精度はパフォーマンスに大きな影響を与えます。空間が非常に高次元で数値が非常に高精度な場合、非常に詳細で複雑な情報を表すことができますが、トレーニングと実行に費用がかかる、より大規模なAIモデルが必要となります。生成されるベクトルはより多くのストレージ容量を必要とし、距離を計算するのにより多くの計算サイクルが必要です。セマンティック埋め込みモデルを使用するには、精度とリソース消費の間で重要なトレードオフを行う必要があります。

ユーザーの柔軟性を最大化するために、Jinaモデルはマトリョーシカ表現学習と呼ばれる技術で訓練されています。これにより、モデルは最も重要な意味的区別を埋め込みベクトルの最初の次元に前もってロードするため、より高い次元を切り捨てても良好なパフォーマンスを得ることができます。

実際には、これはJinaモデルのユーザーが埋め込みの次元数を選択できることを意味します。次元を少なく選択すると精度は低下しますが、パフォーマンスの低下は軽微です。ほとんどのタスクで、Jinaモデルのパフォーマンス指標は、埋め込みサイズを50％縮小するたびに1〜2％低下し、サイズが約95％小さくなります。

非対称検索

意味的類似性は通常、対称的に測定されます。「cat」と「dog」を比較したときに得られる値は、「dog」と「cat」を比較したときに得られる値と同じです。しかし、情報検索に埋め込みを使用する場合、対称性を破り、検索オブジェクトをエンコードする方法とは異なる方法でクエリをエンコードすると、埋め込みがより効果的に機能します。

これは、埋め込みモデルをトレーニングする方法によるものです。トレーニングデータには、単語のような同じ要素が多くの異なるコンテキストでインスタンスとして含まれており、モデルは要素間のコンテキスト上の類似点と相違点を比較することで意味論を学習します。

例えば、「animal」という単語は、「cat」や「dog」と同じ文脈にはあまり出てこないので、「animal」の埋め込みは「cat」や「dog」に特に近いわけではない可能性があります。

これにより、「animal」のクエリで猫や犬に関するドキュメントが検索される可能性が低くなります。これは目標とは逆の結果となります。そのため、代わりに、クエリの場合と検索のターゲットの場合で「animal」を異なる方法でエンコードします。

非対称検索とは、クエリに異なるモデルを使用したり、埋め込みモデルを特別に訓練して、検索のために格納する際に一方向にエンコードし、クエリを別の方向にエンコードすることを意味します。

マルチベクトル埋め込み

単一の埋め込みは、インデックス付きデータベースの基本的なフレームワークに適合するため、情報検索に適しています。検索キーとして単一の埋め込みベクトルを使用して、検索用のオブジェクトを格納します。ユーザーがドキュメントストアをクエリする際、そのクエリは埋め込みベクトルに変換され、そのキーが（高次元の埋め込み空間において）クエリ埋め込みに最も近いドキュメントが一致候補として取得されます。

マルチベクトル埋め込みの動作は少し異なります。クエリと格納されたオブジェクト全体を示す固定長のベクトルを生成する代わりに、それらの小さな部分を表す埋め込みのシーケンスを生成します。これらの部分は通常、テキストの場合はトークンまたは単語、視覚データの場合は画像タイルです。これらの埋め込みは、その文脈における部分の意味を反映しています。

例えば、次の文を考えてみましょう。

• She had a heart of gold（彼女は心優しい人でした）.
• She had a change of heart（彼女は心変わりしたのです）.
• 彼女は心臓発作を起こしました。

表面的には非常によく似ているように見えますが、マルチベクトルモデルでは「heart」の各インスタンスに対して非常に異なる埋め込みが生成され、文全体の文脈の中でそれぞれが別の意味を持つことが示されます。

2つのオブジェクトのマルチベクトル埋め込みを比較する場合、多くの場合、面取り距離の測定が必要になります。つまり、1 つのマルチベクトル埋め込みの各部分を別のマルチベクトル埋め込みの各部分と比較し、それらの間の最小距離を合計します。以下に説明するJinaリランカーを含む他のシステムでは、類似性を評価するために特別にトレーニングされたAIモデルにそれらを入力します。マルチベクトル埋め込みには単一ベクトル埋め込みよりもはるかに詳細な情報が含まれているため、通常、両方のアプローチは単一ベクトル埋め込みを単純に比較するよりも精度が高くなります。

しかし、マルチベクトル埋め込みはインデキシングにはあまり適していません。次のセクションのjina-colbert-v2モデルで説明するように、これらはタスクのリランキングによく使用されます。

Jina埋め込みモデル

Jina埋め込みv4

jina-embeddings-v4は、広く使用されているさまざまな言語の画像とテキストをサポートする、38億（3.8x10⁹）パラメーターの多言語およびマルチモーダル埋め込みモデルです。視覚的知識と言語的知識を活用する新しいアーキテクチャを使用して両方のタスクのパフォーマンスを向上させ、画像検索、特に視覚的ドキュメント検索で優れた性能を発揮します。これは、チャート、スライド、マップ、スクリーンショット、ページスキャン、ダイアグラムなどの画像を処理することを意味します。これらは一般的な種類の画像で、しばしば重要な埋め込まれたテキストが含まれており、実世界のシーンの画像で訓練されたコンピュータービジョンモデルの範囲外にあります。

コンパクトなLow-Rank Adaptation（LoRA）アダプターを使って、このモデルを複数の異なるタスクに最適化しました。これにより、メモリや処理の追加コストを最小限に抑えながら、いずれのタスクでもパフォーマンスを犠牲にすることなく、単一のモデルを複数のタスクに特化させることができます。

主な機能には以下のようなものがあります。

• ビジュアルドキュメント検索における最先端のパフォーマンス、および大規模モデルをはるかに凌駕する多言語テキストと通常の画像のパフォーマンス。
• 大きなインプットコンテキストサイズのサポート：32,768トークンは約80ページのダブルスペースの英語テキストに相当し、20メガピクセルは4,500 x 4,500ピクセルの画像に相当します。
• 最大2048次元から128次元まで、ユーザーが選択した埋め込みサイズ。経験的に、そのしきい線を下回るとパフォーマンスが劇的に低下することがわかりました。
• 単一埋め込みとマルチベクトル埋め込みの両方をサポートします。テキストの場合、マルチベクトル出力は、インプットトークンごとに1つの128次元埋め込みで構成されます。画像の場合、28x28ピクセルタイルごとに1つの128次元埋め込みを生成します。
• 目的のために特別に訓練された2つのLoRAアダプターによる非対称検索最適化。
• 意味的類似度計算に最適化されたLoRAアダプター。
• プログラミング言語とITフレームワークへの特別なサポート。LoRAアダプターを介してのサポートも提供します。

私たちは、幅広い一般的な検索、自然言語理解、AI分析タスクのための汎用的な多目的ツールとしてjina-embeddings-v4を開発しました。機能を考えると比較的小規模なモデルですが、導入には依然としてかなりのリソースが必要であり、クラウドAPI経由または高ボリューム環境での使用に最適です。

Jina embeddings v3

jina-embeddings-v3は、6億未満のパラメーターを持つ、コンパクトで高性能な多言語のテキストのみの埋め込みモデルです。最大8192トークンのテキストインプットをサポートし、デフォルトの1024次元から64次元まで、ユーザーが選択したサイズの単一ベクトル埋め込みを出力します。

私たちは、情報検索や意味的類似性だけでなく、感情分析やコンテンツモデレーションなどの分類タスク、ニュースの集約や推奨などのクラスタリングタスクなど、さまざまなテキストタスク向けにjina-embeddings-v3をトレーニングしてきました。jina-embeddings-v4と同様に、このモデルは次の使用カテゴリーに特化したLoRAアダプターを提供します。

• 非対称検索
• 意味的類似性
• 分類
• クラスタリング

jina-embeddings-v3 は jina-embeddings-v4よりもはるかに小さいモデルであり、インプットコンテキストのサイズが大幅に削減されていますが、操作にかかるコストは少なくなります。それにもかかわらず、テキストに関しては非常に競争力のあるパフォーマンスを有し、多くのユースケースにとってより良い選択肢です。

Jinaコード埋め込み

Jinaの専門的なコード埋め込みモデルであるjina-code-embeddings（0.5bおよび1.5b）は、15プログラミング方式とフレームワーク、さらにコンピューティングや情報技術に関連する英語のテキストをサポートしています。これらは、それぞれ5億 （0.5x10⁹）と15億（1.5x10⁹）のパラメーターを持つコンパクトなモデルです。どちらのモデルも、最大32,768トークンのインプットコンテキストサイズをサポートしており、ユーザーは出力の埋め込みサイズを選択（小さいモデルでは896から64次元、大きいモデルでは1536から128次元）できます。

これらのモデルは、LoRAアダプターではなくプレフィックスチューニングを使用して、5つのタスク固有の特殊化のための非対称検索をサポートしています。

• コードからコードへ。さまざまなプログラミング言語で同様のコードを取得できます。コードの調整、コードの重複排除、移植とリファクタリングのサポートに使用されます。
• 自然言語からコードへ。自然言語クエリ、コメント、説明、ドキュメントに合わせたコードを取得します。
• コードから自然言語へ。コードをドキュメントまたはその他の自然言語テキストと一致させます。
• コード間の補完。既存のコードを完成させたり強化したりするために、関連するコードを提案します。
• 技術的な内容のQ＆A。情報技術に関する質問に対する自然言語による回答を特定します。テクニカルサポートのユースケースに最適です。

これらのモデルは、比較的小さい計算コストで、コンピューターのドキュメント作成やプログラミング資料に関連するタスクに優れたパフォーマンスを提供します。開発環境やコードアシスタントに統合するのに適しています。

Jina ColBERT v2

jina-colbert-v2は、5億6000万のパラメーターを持つマルチベクトルテキスト埋め込みモデルです。多言語対応で、89言語の素材を使用してトレーニングされており、可変の埋め込みサイズと非対称検索をサポートしています。

前述のように、マルチベクトル埋め込みはインデックス作成にはあまり適していませんが、他の検索戦略の結果の精度を高めるのに非常に役立ちます。jina-colbert-v2を使用すると、マルチベクトル埋め込みを事前に計算し、それを使用してクエリ時に検索候補をリランキングすることができます。このアプローチは、次のセクションのリランキングモデルの1つを使用するほど正確ではありませんが、クエリや候補の一致ごとにAIモデル全体を呼び出すのではなく、格納されているマルチベクター埋め込みを比較するだけなので、はるかに効率的です。これは、リランキングモデルを使用する際の遅延や計算オーバーヘッドが大きすぎる、または比較する候補の数が多すぎるユースケースに最適です。

このモデルは、インプットトークンごとに埋め込みのシーケンスを出力し、ユーザーは128次元、96次元、または64次元の埋め込みのトークンを選択できます。候補テキストの一致は8,192トークンに制限されます。クエリは非対称にエンコードされるため、ユーザーはテキストがクエリか候補一致かを指定する必要があり、クエリは32トークンに制限する必要があります。

Jina CLIP v2

jina-clip-v2は、9億パラメーターのマルチモーダル埋め込みモデルであり、テキストが画像のコンテンツを説明する場合に、テキストと画像が近い埋め込みを生成するようにトレーニングされています。その主な用途は、テクスチャクエリに基づいて画像を取得することですが、テキストからテキストへの検索とテキストから画像への検索に別々のモデルを必要としないため、高性能のテキストのみのモデルでもあり、ユーザーのコスト削減に役立ちます。

このモデルは8,192トークンのテキストインプットコンテキストをサポートし、画像は埋め込みを生成する前に512x512ピクセルに拡大されます。

対照言語画像事前トレーニング（CLIP）アーキテクチャは、トレーニングと操作が簡単で、非常にコンパクトなモデルを作成できますが、基本的な制限がいくつかあります。あるメディアの知識を別のメディアでのパフォーマンスの向上に活用することはできません。あるメディアを利用して別のメディアのパフォーマンスを向上させることはできません。そのため、「dog」と「cat」という単語の意味はどちらも「car」よりも近いことはわかっていても、犬の写真と猫の写真はどちらも車の写真よりも関連性が高いことは必ずしもわかっていません。

また、これらはモダリティギャップと呼ばれる問題も抱えています。これはつまり、犬に関するテキストの埋め込みは、犬の画像の埋め込みよりも、猫に関するテキストの埋め込みに近い可能性が高いということです。この制限のため、CLIPはテキストから画像への検索モデルとして、またはテキストのみのモデルとして使用し、1つのクエリ内でこれら2つを混在させないことをお勧めします。

リランキングモデル

リランキングモデルは、1つまたは複数の候補一致と、クエリをモデルへのインプットとして取り、それらを直接比較して、はるかに高い精度の一致を生成します。

原理的には、各クエリを保存されている各ドキュメントと比較することで、情報検索にリランキングを直接使用できますが、これは計算コストが非常に高く、最小のコレクション以外では実用的ではありません。そのため、リランカーは、埋め込みベースの検索やその他の検索アルゴリズムなど、他の手段によって見つかった候補一致の比較的短いリストを評価するために使用される傾向があります。リランキングモデルは、検索を実行するとクエリが異なるデータセットを持つ個別の検索システムに送信され、それぞれが異なる結果を返す可能性があるハイブリッド検索スキームやフェデレーション検索スキームに最適です。多様な結果を1つの高品質な結果に統合する場合に非常に効果的です。

埋め込みベースの検索は、保存されているすべてのデータの再インデックスや、結果に対するユーザーの期待の変更など、大きな負担を伴う可能性があります。既存の検索スキームにリランカーを追加することで、検索ソリューション全体を再構築することなく、AIの利点の多くを追加することができます。

Jinaリランカーモデル

Jinaリランカーm0

jina-reranker-m0は、24億（2.4x10⁹）パラメーターのマルチモーダルリランカーで、テキストクエリとテキストや画像からなる候補一致をサポートします。これはビジュアルドキュメント検索の主要モデルであり、PDF、テキストのスキャン、スクリーンショット、テキストなど半構造化情報を含むコンピュータ生成または修正された画像、加えてテキストドキュメントと画像からなる混合データの格納に理想的なソリューションです。

このモデルは、単一のクエリと候補一致を受け取り、スコアを返します。同じクエリを異なる候補で使用すると、スコアは比較可能となり、それらのランク付けに使用できます。クエリテキストや候補テキストや画像を含む最大10,240トークンのインプットサイズをサポートします。画像をカバーするために必要な28x28ピクセルのタイルはすべて、入力サイズを計算するためのトークンとしてカウントされます。

Jinaリランカーv3

jina-reranker-v3は、同等のサイズのモデルに対して最先端のパフォーマンスを備えた6億パラメーターのテキストリランカーです。jina-reranker-m0とは異なり、1つのクエリと最大64件の一致候補のリストを受け取り、ランキング順を返します。クエリとすべてのテキスト候補を含む131,000トークンの入力コンテキストがあります。

Jinaリランカーv2

jina-reranker-v2-base-multilingualは非常にコンパクトで汎用的なリランカーで、関数呼び出しやSQLクエリをサポートする追加の機能を備えています。3億弱のパラメーターで、高速、効率的、正確な多言語テキストリランキングを提供し、テキストクエリにマッチするSQLテーブルと外部関数を選択するための追加サポートもあり、エージェント的なユースケースに適しています。

小規模な生成言語モデル

生成言語モデルは、OpenAIのChatGPT、Google Gemini、AnthropicのClaudeのように、テキストまたはマルチメディアのインプットを受け取り、テキスト出力で応答するモデルです。大規模言語モデル（LLM）と小規模言語モデル（SLM）を明確に区別する境界はありませんが、最先端のLLMを開発、運用、使用する際の実用的な問題はよく知られています。最もよく知られているものは一般公開されていないため、そのサイズを推定することしかできませんが、ChatGPT、Gemini、Claudeは1～3兆（1～3x10¹²）のパラメーター範囲にあると予想されます。

これらのモデルを実行することは、たとえ公開されたものであっても、従来のハードウェアの範囲をはるかに超えており、広大な並列アレイに配置された最先端のチップを必要とします。有料のAPIを使ってLLMにアクセスすることもできますが、これには大きなコストがかかり、レイテンシーも大きく、データ保護、デジタル主権、クラウドの本国送還などの要求と整合させるのは困難です。さらに、その規模のモデルのトレーニングとカスタマイズに関連するコストはかなりの額になる可能性があります。

その結果、最大規模のLLMのすべての機能は備えていないものの、特定の種類のタスクを低コストで同様に実行できる小規模モデルの開発に多大な研究が行われてきました。一般的に、企業は特定の問題に対処するためにソフトウェアをデプロイしますが、AIソフトウェアも同様で、LLMよりもSLMベースのソリューションの方が望ましい場合が多いのです。これらは通常、一般的なハードウェア上で実行でき、実行速度が速く、消費電力が少なく、カスタマイズがはるかに簡単です。

JinaのSLMサービスは、AIを実用的な検索ソリューションに最も効果的に組み込む方法に重点を置いて拡大しています。

Jina SLM

ReaderLM v2

ReaderLM-v2は、ユーザーが提供したJSONスキーマや自然言語命令に基づいて、HTMLをMarkdownまたはJSONに変換する生成言語モデルです。

データの前処理と正規化はデジタルデータの優れた検索ソリューションを開発する上で不可欠な部分ですが、現実世界のデータ、特にウェブから得られる情報は混沌としていることが多く、単純な変換戦略では非常に脆弱になることがよくあります。代わりに、ReaderLM-v2 はウェブページのDOMツリーダンプの混沌を理解し、有用な要素を堅牢に識別できるインテリジェントなAIモデルソリューションを提供します。

15億（1.5x10⁹）パラメーターを持つこのシステムは最先端のLLMよりも3桁コンパクトですが、この1つの狭義のタスクにおいては最先端のLLMと同等のパフォーマンスを発揮します。

Jina VLM

JINA-VLMは、画像に関する自然言語の質問に答えるために訓練された24億（2.4×10⁹）パラメーターの生成言語モデルです。視覚的ドキュメント分析、つまりスキャン、スクリーンショット、スライド、図表、類似の非自然画像データに関する質問に回答する機能を非常に強力にサポートしています。

例：

画像内のテキストの読み取りにも非常に優れています。

しかし、jina-vlmの真に優れた点は、情報収集や人工画像の内容を理解することです。

または：

jina-vlm 自動キャプション生成、製品の説明、画像の代替テキスト、視覚障害者向けのアクセシビリティ用途に最適です。また、検索拡張生成（RAG）システムが視覚情報を使用したり、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に貼り付けます。<YOUR-ELASTIC-AGENT-BUILDER-URL>プレースホルダー値の代わりにファイルを使用します。ここで、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キーを貼り付けて、<YOUR-ELASTIC-API-KEY>プレースホルダーテキストを置き換えます。.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+のゲームに挑戦してみましょう。幸運を祈ります！

関連コンテキストでAIアプリを構築

AIエージェントの構築のスキルを習得できました。また、Strands Agents SDKのようなエージェント開発フレームワークで、A2Aを介してElastic Agent Builderエージェントを使用することがいかに簡単であるかをお分かりいただけたと思います。カスタムデータの関連コンテキストに接続されたAIエージェントの構築にはElasticをお試しください。

当社は最近、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

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

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

FROM kibana_sample_data_ecommerce | WHERE MATCH(customer_full_name, ?name)

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/をご覧ください。

ただし、この 1 つの問題を修正すると、すべてのケースを手動でテストすることができないため、他のクエリが誤って壊れてしまいます。しかし、1つのクエリの変更が他のクエリに波及効果をもたらすかどうかを、開発者やQAチームはどのようにテストできるでしょうか。さらに重要なのは、変更によってクエリが実際に改善されたことをどうやって確認できるかということです。

体系的な評価に向けて

ここで役に立つのが判断リストです。変更を加えるたびに手動の主観的なテストに頼るのではなく、ビジネスケースに関連するクエリの固定セットと、関連する結果を定義できます。

このセットが基準となります。変更を実装するたびに、それを使用して検索が実際に改善されたかどうかを評価します。

このアプローチの価値は、次の点にあります。

• 不確実性の排除：変更が他のクエリに影響を与えるかどうかを心配する必要はなくなり、データが教えてくれます。
• 手動テストの停止：判断セットが記録されると、テストは自動化されます。
• 変更を支援：変更のメリットを裏付ける明確な指標を示すことができます。

判断リストの作成方法

最も簡単な方法の1つは、代表的なクエリを取得して、関連するドキュメントを手動で選択することです。このリストを作成するには2つの方法があります。

• バイナリ判定：クエリに関連付けられた各ドキュメントに関連（通常「1」のスコア）とと非関連（「0」）のシンプルなタグが付けられます。
• 段階的な判断：ここでは、各ドキュメントに異なるレベルのスコアが付けられます。例えば、0から4の尺度を設定します。これはライカート尺度に似ており、0は「全く関連しない」、4は「完全に関連する」を意味し、「関連する」、「やや関連する」などのバリエーションがあります。

検索意図に明確な制限がある場合、つまり「このドキュメントは結果に含まれるべきかどうか」という場合には、バイナリ判断がうまく機能します。

段階的な判断は、グレーゾーンがある場合により役立ちます。一部の結果は他の結果よりも優れているため、「非常に良い」、「良い」、「役に立たない」という結果を取得し、結果の順序とユーザーのフィードバックを評価する指標を使用できます。ただし、段階的な評価尺度には欠点もあります。評価者によってスコアリングレベルの使い方が異なり、判断の一貫性が失われることがある点です。また、評価基準では高得点により重み付けされるため、小さな変更（評価を4ではなく3にするなど）でも、レビュー担当者の意図よりもはるかに大きな変化が評価基準に生じる可能性があります。この主観性が加わることで、段階的な判断はノイズが多くなり、時間の経過とともに管理が難しくなります。

書類を自分で分類する必要がありますか？

必ずしもそうとは限りません。なぜなら、判断リストを作成する方法はいくつかあり、それぞれに利点と欠点があるからです。

• 明示的な判断：ここでは、SMEが各クエリやドキュメントに目を通し、関連性があるかどうか（あるいはどの程度関連性があるか）を手動で判断します。これにより品質と管理は提供されますが、拡張性は低くなります。
• 暗黙的な判断：この方法では、クリック、直帰率、購入などの実際のユーザーの行動に基づいて関連するドキュメントを推測します。このアプローチにより、データを自動的に収集できますが、バイアスがかかる可能性があります。例えば、ユーザーは関連性がなくても上位の結果をクリックする傾向があります。
• AI生成の判断：この最後のオプションでは、モデル（LLMなど）を使用してクエリとドキュメントを自動的に評価します。これは、LLM審査員とも呼ばれます。スケーリングは高速かつ簡単ですが、データの品質は、使用しているモデルの品質と、LLMトレーニングデータがビジネス上の利益とどの程度一致しているかによって異なります。人間の採点者と同様に、LLM審査員も独自のバイアスや不整合を導入する可能性があるため、信頼できる判断の小さなセットに対してその出力を検証することが重要です。LLMモデルは本質的に確率的であるため、 温度 パラメータを0に設定しても同じ結果に対して異なる評価を与えるLLMモデルがよく見られます。

判断セットを作成するための最適な方法を選択するための推奨事項を以下に示します。

• ユーザーのみが適切に判断できる特徴（価格、ブランド、言語、スタイル、製品詳細など）の重要性を決定します。これらが重要な場合は、判断リストの少なくとも一部について明示的な判断が必要です。
• 検索エンジンにすでに十分なトラフィックがある場合は、暗黙的な判断を使用して、クリック、コンバージョン、滞在時間の指標を使用して使用傾向を検出できます。これらの結果は人間が注意深く解釈し、明示的な判断セットと対比させて、バイアスを防御する必要があります（例：ユーザーは、たとえ低いランクの結果がより関連性が高くても、上位にランクされた結果をクリックする傾向があります）。

これに対処するために、位置バイアス除去技術はクリックデータを調整または再重み付けして、実際のユーザーの関心をより適切に反映します。アプローチには以下のようなものがあります。

• 結果のシャッフル：一部のユーザーの検索結果の順序を変更し、位置がクリックにどのように影響するかを推定します。
• クリックモデルにはダイナミックベイジアンネットワーク（DBN）、ユーザーブラウジングモデル（UBM）が含まれます。これらの統計モデルは、スクロール、滞在時間、クリックシーケンス、結果ページへの戻りなどのパターンを使用して、クリックが単なる位置ではなく実際の関心を反映している可能性を推定します。

例：映画評価アプリ

要件

この例を実行するには、稼働しているElasticsearch 8.xクラスター、ローカルまたはElastic Cloud（HostedまたはServerless）、REST APIまたはKibanaへのアクセスが必要です。

ユーザーが映画についての意見をアップロードしたり、見たい映画を検索したりできるアプリを考えてみてください。ユーザー自身がテキストを書くため、タイプミスや表現の多様性がある可能性があります。そのため、検索エンジンがその多様性を解釈し、ユーザーにとって有益な結果を提供できることが不可欠です。

全体的な検索動作に影響を与えずにクエリを反復処理できるようにするために、会社のビジネスチームは、最も頻繁に実行される検索に基づいて、次のバイナリ判定セットを作成しました。

インデックスの作成：

PUT movies
{
  "mappings": {
    "properties": {
      "text": {
        "type": "text"
      }
    }
  }
}

一括リクエスト：

POST /movies/_bulk
{ "index": { "_id": "doc1" } }
{ "text": "DiCaprio performance in The Revenant was breathtaking." }
{ "index": { "_id": "doc2" } }
{ "text": "Inception shows Leonardo DiCaprio in one of his most iconic roles." }
{ "index": { "_id": "doc3" } }
{ "text": "Brad Pitt delivers a solid performance in this crime thriller." }
{ "index": { "_id": "doc4" } }
{ "text": "An action-packed adventure with stunning visual effects." }
{ "index": { "_id": "doc5" } }
{ "text": "A heartbreaking story of love and loss that made me cry for hours." }
{ "index": { "_id": "doc6" } }
{ "text": "One of the saddest movies ever made -- bring tissues!" }
{ "index": { "_id": "doc7" } }
{ "text": "A lighthearted comedy that will make you laugh." }
{ "index": { "_id": "doc8" } }
{ "text": "A science-fiction epic full of action and excitement." }

以下は、このアプリが使用しているElasticsearchクエリです。

GET movies/_search
{
 "query": {
   "match": {
     "text": {
       "query": "DiCaprio performance",
       "minimum_should_match": "100%"
     }
   }
 }
}

判断から指標へ

判断リスト自体は、多くの情報を提供しません。これは、クエリから得られる結果の期待値にすぎません。これらが真価を発揮するのは、検索パフォーマンスを測定するための客観的な指標の計算に使用するときです。

現在、人気の指標のほとんどには以下が含まれます。

• 精度：すべての検索結果の中で本当に関連性の高い結果の割合を測定します。
• リコール：検索エンジンがx件の結果の中で見つけた関連する結果の割合を測定します。
• 割引累積利得（DCG）：最も関連性の高い結果が上位にあるべきであることを考慮して、結果のランキングの品質を測定します。
• 平均逆順位（MRR）：最初の関連結果の位置を測定します。リストの上位にあるほど、スコアも高くなります。

同じ映画評価アプリを例に使い、リコール指標を計算して、クエリに抜け落ちている情報がないかを確認します。

Elasticsearchでは、Ranking Evaluation APIを通じて判断リストを使って指標を計算できます。このAPIは、判断リスト、クエリ、および評価する指標をインプットとして受け取り、クエリ結果と判断リストを比較した値を返します。

次の2つのクエリの判断リストを実行してみましょう。

POST /movies/_rank_eval
{
 "requests": [
   {
     "id": "dicaprio-performance",
     "request": {
       "query": {
         "match": {
           "text": {
             "query": "DiCaprio performance",
             "minimum_should_match": "100%"
           }
         }
       }
     },
     "ratings": [
       {
         "_index": "movies",
         "_id": "doc1",
         "rating": 1
       },
       {
         "_index": "movies",
         "_id": "doc2",
         "rating": 1
       },
       {
         "_index": "movies",
         "_id": "doc3",
         "rating": 0
       },
       {
         "_index": "movies",
         "_id": "doc4",
         "rating": 0
       }
     ]
   },
   {
     "id": "sad-movies",
     "request": {
       "query": {
         "match": {
           "text": {
             "query": "sad movies that make you cry",
             "minimum_should_match": "100%"
           }
         }
       }
     },
     "ratings": [
       {
         "_index": "movies",
         "_id": "doc5",
         "rating": 1
       },
       {
         "_index": "movies",
         "_id": "doc6",
         "rating": 1
       },
       {
         "_index": "movies",
         "_id": "doc7",
         "rating": 0
       },
       {
         "_index": "movies",
         "_id": "doc8",
         "rating": 0
       }
     ]
   }
 ],
 "metric": {
   "recall": {
     "k": 10,
     "relevant_rating_threshold": 1
     }
 }
}

_rank_evalには 2 つのリクエストを使用します。1つはディカプリオクエリ用、もう1つは悲しい映画用です。各リクエストには、クエリと判断リスト（評価）が含まれています。評価に含まれていない文書は判断対象外とみなされるため、すべての文書に等級を付ける必要はありません。計算を行うために、リコールは評価において関連性があると見なされるドキュメントである「関連セット」のみを考慮します。

この場合、ディカプリオのクエリのリコールは1ですが、悲しい映画のリコールは0です。つまり、最初のクエリでは関連する結果をすべて取得できましたが、2 番目のクエリでは何も取得できませんでした。したがって、平均リコールは0.5です。

{
 "metric_score": 0.5,
 "details": {
   "dicaprio-performance": {
     "metric_score": 1,
     "unrated_docs": [],
     "hits": [
       {
         "hit": {
           "_index": "movies",
           "_id": "doc1",
           "_score": 2.4826927
         },
         "rating": 1
       },
       {
         "hit": {
           "_index": "movies",
           "_id": "doc2",
           "_score": 2.0780432
         },
         "rating": 1
       }
     ],
     "metric_details": {
       "recall": {
         "relevant_docs_retrieved": 2,
         "relevant_docs": 2
       }
     }
   },
   "sad-movies": {
     "metric_score": 0,
     "unrated_docs": [],
     "hits": [],
     "metric_details": {
       "recall": {
         "relevant_docs_retrieved": 0,
         "relevant_docs": 2
       }
     }
   }
 },
 "failures": {}
}

クエリ内の単語の100%がドキュメント内で見つかることを要求することで、おそらく関連する結果が除外されるため、minimum_should_matchパラメータを厳しすぎるのかもしれません。minimum_should_matchパラメーターを削除して、クエリで1つの単語しか見つかっていない文書が関連性があると見なされるようにしましょう。

POST /movies/_rank_eval
{
 "requests": [
   {
     "id": "dicaprio-performance",
     "request": {
       "query": {
         "match": {
           "text": {
             "query": "DiCaprio performance"
           }
         }
       }
     },
     "ratings": [
       {
         "_index": "movies",
         "_id": "doc1",
         "rating": 1
       },
       {
         "_index": "movies",
         "_id": "doc2",
         "rating": 1
       },
       {
         "_index": "movies",
         "_id": "doc3",
         "rating": 0
       },
       {
         "_index": "movies",
         "_id": "doc4",
         "rating": 0
       }
     ]
   },
   {
     "id": "sad-movies",
     "request": {
       "query": {
         "match": {
           "text": {
             "query": "sad movies that make you cry"
           }
         }
       }
     },
     "ratings": [
       {
         "_index": "movies",
         "_id": "doc5",
         "rating": 1
       },
       {
         "_index": "movies",
         "_id": "doc6",
         "rating": 1
       },
       {
         "_index": "movies",
         "_id": "doc7",
         "rating": 0
       },
       {
         "_index": "movies",
         "_id": "doc8",
         "rating": 0
       }
     ]
   }
 ],
 "metric": {
   "recall": {
     "k": 10,
     "relevant_rating_threshold": 1
     }
 }
}

ご覧のように、2つのクエリのうちの1つでminimum_should_matchパラメーターを削除すると、両方のクエリの平均リコール率は1になります。

{
  "metric_score": 1,
  "details": {
    "dicaprio-performance": {
      "metric_score": 1,
      "unrated_docs": [],
      "hits": [
        {
          "hit": {
            "_index": "movies",
            "_id": "doc1",
            "_score": 2.0661702
          },
          "rating": 1
        },
        {
          "hit": {
            "_index": "movies",
            "_id": "doc3",
            "_score": 0.732218
          },
          "rating": 0
        },
        {
          "hit": {
            "_index": "movies",
            "_id": "doc2",
            "_score": 0.6271719
          },
          "rating": 1
        }
      ],
      "metric_details": {
        "recall": {
          "relevant_docs_retrieved": 2,
          "relevant_docs": 2
        }
      }
    },
    "sad-movies": {
      "metric_score": 1,
      "unrated_docs": [],
      "hits": [
        {
          "hit": {
            "_index": "movies",
            "_id": "doc7",
            "_score": 2.1307156
          },
          "rating": 0
        },
        {
          "hit": {
            "_index": "movies",
            "_id": "doc5",
            "_score": 1.3160692
          },
          "rating": 1
        },
        {
          "hit": {
            "_index": "movies",
            "_id": "doc6",
            "_score": 1.190063
          },
          "rating": 1
        }
      ],
      "metric_details": {
        "recall": {
          "relevant_docs_retrieved": 2,
          "relevant_docs": 2
        }
      }
    }
  },
  "failures": {}
}

要約すると、minimum_should_match: 100%句を削除すると、両方のクエリで完璧なリコールが得られます。

これで完了でしょうか？

安心するのはまだ早いです。

リコールを改善することで、より幅広い結果を得る道が開かれます。ただし、それぞれの調整にはトレードオフが伴います。だからこそ、完全なテストケースを定義し、異なる指標を使って変更を評価することが重要です。

判断リストと指標を使用すると、変更をバックアップするデータが得られるため、変更を行うときに盲目的に変更を行うことがなくなります。検証は手動で繰り返し行う必要がなくなり、変更を1つのユースケースだけでなく複数のユースケースでテストできるようになります。さらに、A/Bテストでは、どの構成がユーザーやビジネスケースに最適かをライブでテストできるため、技術的な指標と実際の指標から完全に把握できます。

判断リストの使用に関する最終的な推奨事項

判断リストを扱うことは、単に測定することだけでなく、自信を持って反復作業を行うためのフレームワークを作ることでもあります。これを実現するには、次の推奨事項に従ってください。

1. 規模にこだわらずとにかく始める。それぞれ50個の判断リストを持つ10,000個のクエリを用意する必要はありません。ビジネスケースの最も重要な5〜10個のクエリを特定し、結果の冒頭にどの文書が表示されたいかを定義するだけで十分です。これですでに基礎が整いました。通常は、上位クエリと結果なしのクエリから始めるのが望ましいです。また、精度のような設定が簡単な指標でテストを開始し、複雑さを上げていくこともできます。
2. ユーザーとともに検証する。本番環境でのA/Bテストで数値を補完します。こうすることで、指標で良さそうに見える変更が実際に効果を生んでいるかどうかを知ることができます。
3. リストをアクティブに保つ。ビジネスケースは進化し、重要な問い合わせも進化していきます。新たなニーズを反映するために、定期的に判断を更新してください。
4. フローの一部に組み込む。判断リストを開発パイプラインに統合しましょう。各構成の変更、同義語、またはテキスト分析が基本リストに対して自動的に検証されることを確認します。
5. 技術的な知識と戦略を結び付ける。精度やリコールなどの技術的な指標の測定にとどまらず、評価結果をビジネスの成果に役立てましょう。

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で検索し、金融と市場のいずれかワークフローを焦点を当てた検索戦略をワークフローで決定できる動的なワークフローを作成します。このアプローチにより、手動クエリ作成の複雑さが軽減され、ベンチャーキャピタルアナリストの柔軟性と精度が向上します。

変数コントロールとは何ですか？

Kibanaのダッシュボードを使用したことがある方なら、クラシックなダッシュボードコントロール（データの値を表示する便利なドロップダウン）をご存知でしょう。これにより、数回のクリックでフィルタリングできます。

変数コントロールは表面上では似ていますが、巧妙な工夫が施されています。ダッシュボード上のすべてのパネルを自動的にフィルター処理するのではなく、個々の可視化内の ES|QLクエリに直接プラグインすることができます。

つまり、各コントロールを適用する場所をユーザーが決定できるということです。さらに、時間間隔の調整、内訳フィールドの切り替え、可視化パラメーターの即時変更など、さまざまなクリエイティブなトリックに使用できます。基本的に、ダッシュボードに真のインタラクティブな体験を提供し、より速く、より簡単に洞察を得られるようにしています。

変数コントロールのユースケース

変数コントロールは便利そうですが、実際に何ができるのでしょうか？ダッシュボードをレベルアップさせる例をいくつかご紹介します。

選択された可視化をフィルター

一部の可視化をフィルターし、他の可視化はそのままにしておきたい場合は、変数コントロールがまさに最適です。必要なパネルを選択して、可視化の背後にあるES|QLクエリでそれらを接続できます。

異なる時間間隔を選択

ユーザーが「5分」、「1時間」、「1日」など、適切な時間枠を切り替えることができるようにします。事前定義された間隔で変数コントロールを構築し、それを時系列クエリに接続します。

機能を変更

各操作ごとに複数のチャートを作成する代わりに、ダッシュボードユーザーが最大値、平均値、異なるパーセンタイル、またはその他のアグリゲーターを選択できるようにします。

異なるフィールドでグループ化

調査中に、データをさまざまな次元で分類する必要がある場合があります。変数コントロールを使用すると、複数の「グループ化」フィールドを定義し、ダッシュボードユーザーが分析情報を明らかにするのに役立つフィールドを選択できるようにすることができます。

作成方法

変数コントロールを作成する最も簡単な（そしておそらく最も楽しい）方法は、可視化のES|QLクエリエディタから直接作成することです。クエリを入力し始め、オートコンプリートメニューを使用すれば、Kibanaが役立つコントロールを自動的に作成します。

ただし、変数自体から開始したい場合は「パネルを追加」→「コントロール」→「変数コントロール」に進み、コントロールを作成した後で変数を可視化に追加することもできます。

例1：複数値選択によるフィルタリングコントロール

1. ES|QLクエリを利用した可視化を選択し、WHERE句内の「コントロールを作成」をクリックします。

2. 自動的に変数作成のポップアップにリダイレクトされます。ここでは「クエリからの値」タイプが自動で選択され、変数の名前も既に入力されています。可視化クエリで動作するよう、コントロールの名前は常に「?...」で始める必要があります。

通常、フィールドから値を取得し、ダッシュボードで選択した時間範囲に応じて値を更新するには、次のようなクエリが必要になります。

FROM 
| WHERE @timestamp <=?_tend and @timestamp >?_tstart
| STATS BY 

3. コントロールを保存すると、それがダッシュボードのトップに表示され、可視化クエリが変数コントロール名で更新されます。

4. コントロールに多重選択を追加したい場合は、ステップ2でクエリ内の MV_CONTAINS 関数を使用し、「複数選択を許可」を選択する必要があります（9.3以降で利用可能）。

例 2: 時間間隔制御

時系列を構築する場合は、日付ヒストグラム間隔に変数コントロールを簡単に追加できます。

1. 時系列のES|QLクエリを記述するときは、「コントロールを作成」をクリックします。変数を間隔用に作成する際は、BUCKET の代わりに TBUCKET を使用する方が良いです。これにより、「1 hour」、「1 day」などの見やすい間隔を受け入れることができます。TBUCKETには、時間範囲に自動的に適応できる自動オプションも近日中に導入される予定です。

2. ドロップダウンメニューでオプションを入力する間隔を定義します。

3. ドロップダウンメニューで異なる間隔を選択し、可視化がどのように変化するかを確認します。

例3：関数の変数

1. 「静的値」タイプのコントロールを使用して変数を作成し、ドロップダウン値に関数名を追加します。関数を置き換えるには、「??...」で始まる変数名を使用することが重要です。

2. ES|QLクエリに変数名を含めます。

例4：フィールドの変数

1. 「静的値」タイプのコントロールを使用して、必要なフィールドの名前を書き留めることができます。フィールドで機能させるためには「??...」で始まる変数名を使用することが重要です。

2. 可視化クエリで任意の場所に変数を参照します。

Discoverの変数コントロール

変数コントロールは単なるダッシュボードの特徴ではなく、DiscoverのES|QLエディターでも直接利用可能です。Discoverでより高速なデータ探索エクスペリエンスを実現するコントロールを構築し、それをダッシュボードに表示したり、その逆を行ったりすることができます。

技術的な詳細

ここまでで、変数コントロールには、クエリのどの部分を参照できるか、使用すべき命名プレフィックス（値の場合は「?...」、フィールドまたは関数の場合は「??...」）などのいくつかのルールがあることに気付かれたでしょう。これは、変数がクライアント上で行われる単純な文字列置換ではなく、実際にはクエリ言語自体の第一級オブジェクトであるためです（ES|QL ではパラメーターと呼ばれます）。

この設計にはいくつかの大きな利点があります。1つは、Kibanaが各変数のコンテキストを理解できるため、設定を自動的に生成して事前入力できることです。また、この言語が変数の入力を厳密に検証し、悪意のある挿入を防ぎ、何かおかしい点があれば適切にエラーを出力するため、安全性もはるかに高くなります。さらに、複雑な検証とエラー処理をクライアントではなくサーバー側に移動することで、パフォーマンスと安定性が向上します。パフォーマンスに関する注意点として、ベストプラクティスは、高速クエリを含む変数を構築することです。これにより、ダッシュボードよりも先に読み込まれ、遅いクエリがダッシュボード全体のパフォーマンスに影響を与えることを防ぎます。

もちろん、このアーキテクチャーにも（現時点では）いくつかの制限があります。変数はまだフィルタリング用の「任意」オプションをサポートしておらず、現在、LIKE やFROM（データソースの切り替え用）のような特定の演算子では使用できません。幸い、当社はこれらの機能を追加するために積極的に取り組んでいます。

コントロールの今後

この機能はまだ完成ではありません。以下のような改善を予定しています。

✨ ダッシュボードのどこにでもコントロールを配置できる機能

✨ コントロールの連鎖（一つのコントロールの出力が次のコントロールのインプットになるよう）

✨ 変数の「任意」選択のようなより良い選択オプション

✨ 新しいコントロールタイプ（検索するタイプのコントロールとデータソースの変数）

✨ さらに、ユーザーの皆様のご要望に応え、通常コントロールの事前フィルタリングなどの操作性の改善

アイデアやご意見があれば、ぜひお聞かせください。

要約

まず、現状をお伝えしましょう。Elasticsearchは、強力なベクトルデータベースとして確立され、大規模な類似性検索に対して豊富な特徴と強力なパフォーマンスを提供しています。スカラー量子化、Better Binary Quantization（BBQ）、SIMDベクトル演算、DiskBBQのようなよりディスク効率の高いアルゴリズムなどの機能により、すでにベクトルワークロードの管理に効率的かつ柔軟な選択肢を提供しています。

NVIDIA cuVSをベクトル検索タスク用の呼び出し可能なモジュールとして統合することで、ベクトルインデキシングのパフォーマンスと効率を大幅に向上させ、大規模なベクトルワークロードをより良くサポートすることを目指しています。

課題

高性能ベクトルデータベースを構築する上で最も困難な課題の一つは、ベクトルインデックス（HNSWグラフ）を構築することです。インデックス構築は、すべてのベクトルが他の多数のベクトルと比較されるため、すぐに数百万、あるいは数十億の算術演算によって支配されるようになります。さらに、インデックスのライフサイクル操作、例えば圧縮やマージなどは、インデキシングの全体的な計算オーバーヘッドをさらに増加させる可能性があります。データ量と関連するベクトル埋め込みが指数関数的に増加するにつれ、大規模な並列処理と高スループットの数学演算用に構築された高速コンピューティングGPUは、これらのワークロードを処理するのに理想的な位置にあります。

Elasticsearch-GPUプラグインの登場

NVIDIA cuVSは、GPUによるベクトル検索とデータクラスタリングのためのオープンソースCUDA-Xライブラリであり、AIおよび推奨ワークロード向けの高速インデックス構築と埋め込み検索を可能にします。

ElasticsearchはcuVSをcuvs-javaを通じて使用しています。cuvs-javaはコミュニティが開発し、NVIDIAが保守するオープンソースライブラリです。cuvs-javaライブラリは軽量で、cuVS C APIをベースにPanama Foreign Functionを使用して、cuVSの特徴をJavaらしい方法で公開しつつ、モダンな高性能を維持しています。

cuvs-javaライブラリは新しいElasticsearchプラグインに統合されています。そのため、GPU上でのインデキシングを同じElasticsearchノードとプロセスで実行でき、外部のコードやハードウェアを提供する必要はありません。CUVsライブラリがインストールされていて、GPUが存在して構成されている場合、インデキシング中にElasticsearchはGPUを使用してベクターインデキシング処理を高速化します。ベクトルはGPUに提供され、GPUはCAGRAグラフを構築します。その後、このグラフはHNSW形式に変換され、CPU上でのベクトル検索にすぐに利用可能になります。構築されたグラフの最終的な形式は、CPU上に構築されるものと同じです。これによりElasticsearchは、基盤となるハードウェアがサポートしている場合、GPUを活用して高スループットのベクトルインデックスを作成し、CPUのパワーを他のタスク（同時検索やデータ処理など）に解放することができます。

インデックス構築の加速

ElasticsearchにGPUアクセラレーションを統合する一環として、cuvs-javaにいくつかの機能強化が行われ、効率的なデータのインプット/出力と関数呼び出しに焦点が当てられました。主要な機能強化は、cuVSMatrixを使用して、Javaヒープ、オフヒープ、またはGPUメモリに存在するベクトルを透過的にモデル化することです。これにより、データをメモリとGPU間で効率的に移動でき、潜在的に数十億のベクトルの不要なコピーを回避できます。

この基礎となるゼロコピー抽象化のおかげで、GPUメモリへの転送とグラフの取得の両方が直接実行できます。インデキシング中、ベクトルは最初にJavaヒープ上のメモリにバッファリングされ、その後GPUに送られてCagraグラフを構築します。その後、グラフはGPUから取得され、HNSW形式に変換され、ディスクに保存されます。

マージ時には、ベクトルはすでにディスクに格納されており、Javaヒープを完全にバイパスします。インデックスファイルはメモリマップされ、データは直接GPUメモリに転送されます。この設計は、float32やint8などのさまざまなビット幅にも簡単に対応し、他の量子化スキームにも自然に拡張できます。

実際のパフォーマンス

数字を見てみる前に、少し背景を説明しておきましょう。Elasticsearchのセグメントマージは通常、インデキシング中にバックグラウンドで自動的に実行されるため、分離してベンチマークをとることが難しくなります。再現可能な結果を得るために、制御された実験でforce-mergeを使用してセグメントのマージを明示的にトリガーしました。force-mergeはバックグラウンドマージと同じ基礎となるマージ操作を実行するので、実際のインデキシングワークロードでは正確な効果が異なる場合でも、そのパフォーマンスは期待される改善を示す有用な指標となります。

さて、数字を見てみましょう。

最初のベンチマーク結果は非常に有望です。ベンチマークは、ローカルに接続されたNVMeストレージを持つAWS g6.4xlargeインスタンスで実行しました。Elasticsearchのシングルノードは、デフォルトの最適なインデキシングスレッド数（各物理コアに1つずつの計8つ）を使用し、マージスロットリング（高速NVMeディスクではあまり適用されません）を無効にするように設定しました。

データセットにはOpenAI Rallyベクトルトラックから取得した1,536次元のベクトル260万個をbase64文字列としてエンコードし、float32 hnswとしてインデックスして使用しました。すべてのシナリオにおいて、構築されたグラフは最大95%のリコールレベルを達成します。結果は以下となりました。

• インデキシングのスループット：メモリ内バッファのフラッシュ中にグラフ構築を GPU に移動することで、スループットが約 12 倍向上します。
• 強制マージ：インデキシングが完了した後、GPUはセグメントのマージを加速し続け、強制マージフェーズを約7倍高速化します。

• CPU使用率：グラフ構築をGPUにオフロードすると、平均およびピーク時のCPU使用率が大幅に削減されます。以下のグラフは、インデキシングとマージ中のCPU使用率を示しており、これらの操作をGPUで実行すると使用率がどれだけ低くなるかを強調しています。GPUインデキシング中のCPU使用率が低下すると、CPUサイクルが解放され、検索パフォーマンスの向上に向けることができます。

• リコール：CPU実行とGPU実行の精度は実質的に同じですが、GPUで構築されたグラフのリコールはわずかに高くなります。

別の次元での比較：価格

先ほどの比較では、意図的に同一のハードウェアが使用されており、唯一の違いはインデキシング中にGPUが使用されたかどうかでした。この設定は、生のコンピューティング効果を分離するのに役立ちますが、コストの観点から比較することもできます。

GPUアクセラレーション構成とほぼ同じ時間単価で、同等のCPUおよびメモリリソースの約2倍（32個のvCPU（AMD EPYC）と64GBのRAM）を備えたCPUのみのセットアップをプロビジョニングでき、インデキシングスレッドの数を2倍の16に増やすことができます。

比較を公平かつ一貫性のあるものにするために、このCPUのみの実験をAWS g6.8xlargeインスタンスで実行しました。GPUは明示的に無効になっています。これにより、GPUアクセラレーションとCPUのみのインデキシングのコストパフォーマンスのトレードオフを評価する際、他のすべてのハードウェア特性を一定に保つことができました。

予想どおり、より強力なCPUインスタンスでは、上記のセクションのベンチマークと比較してパフォーマンスが向上しています。しかし、このより強力なCPUインスタンスを元のGPUアクセラレーション結果と比較すると、GPUは、リコールレベル最大95%に達するグラフを構築しながら最大5倍のインデキシングスループット向上、最大6倍のフォースマージと、依然として大幅なパフォーマンス向上を提供します。

結論

エンドツーエンドのシナリオでは、NVIDIA cuVSによるGPUアクセラレーションにより、インデキシングのスループットが約12倍向上し、force-mergeのレイテンシが7倍減少し、CPU使用率が大幅に低下します。これは、ベクトルインデキシングとマージワークロードがGPUアクセラレーションから大きな恩恵を受けることを示しています。コスト調整後の比較では、GPUアクセラレーションは引き続き大幅なパフォーマンス向上をもたらし、インデキシングのスループットは約5倍、force-merge操作は6倍高速化されます。

GPUアクセラレーションによるベクトルインデキシングは、現在Elasticsearch 9.3の技術プレビューで計画されており、2026年初頭にリリース予定です。

続報をお楽しみに。

ES|QLを使用してデータ分析ワークフローを変革するElasticsearch 9.2の特徴を見てみましょう。

データ相関の革命：よりスマート高速、柔軟になったLookup Join

ES|QLのLOOKUP JOINコマンドはElasticsearch 9.2で大幅に変更され、効率性と汎用性が飛躍的に向上しました。LOOKUP JOINは、ES|QLクエリ結果テーブルのデータを、指定されたルックアップモードインデックスの一致するレコードと結合します。結合フィールド内の一致する値に基づいて、ルックアップ インデックスのフィールドが新しい列として結果テーブルに追加されます。以前は、データの結合は単一のフィールドと単純な等式に制限されていましたが、これが改善されました。これらの機能強化により、複雑なデータ相関シナリオに簡単に対処できるようになります。

Lookup Joinの主な機能強化は次のとおりです。

• 複数フィールド結合：複数のフィールドを簡単に結合できます。例えば、application_logs を service_name、environment の service_registry と結合する場合 version:

FROM application_logs
| LOOKUP JOIN service_registry ON service_name, environment, version

• 式を使用して複雑なjoin述語を活用（テクニカルプレビュー）：

もはや、単純な等式に制限されることはありません。LOOKUP JOINでは、複数の条件を相関に指定し、==、!=、、<=、>= を含む 二項演算子の範囲を組み込むことができます。つまり、非常に微妙な結合条件を作成できるようになり、データに対してより高度な質問をすることができるようになります。

例1：サービスごとのSLAしきい値を使用したアプリケーションメトリクスの検索

FROM application_metrics
| LOOKUP JOIN sla_thresholds
      ON service_name == sla_service AND response_time > sla_response_time

例2：このクエリは、時間とともに変化する地域の価格ポリシーに基づいて支払われるべき金額を計算します。複雑な日付範囲と等しい条件に基づく3つのデータセットを統合し、最終的に due_amountを算出します。2番目のルックアップ結合では、 meter_readingsインデックスのmeasurement_dateフィールドとcustomersインデックスのregion_idフィールドを使用してpricing_policiesインデックスに結合し、特定のregionとmeasurement_dateの正しい価格設定ポリシーを検索します。

FROM meter_readings
| LOOKUP JOIN customers
      ON meter_id
| LOOKUP JOIN pricing_policies
      ON
        region_id == region AND
          measurement_date >= policy_begin_date AND
          measurement_date < policy_end_date
| EVAL due_amount = (kwh_consumed * rate_per_kwh + base_charge) * (1 + tax_rate)
| EVAL period = policy_name
| KEEP customer_name, period, due_amount, measurement_date, kwh_consumed,
    rate_per_kwh, base_charge, tax_rate
| SORT measurement_date

• フィルターされた結合のパフォーマンスが大幅に向上：

ルックアップテーブル条件を使用してフィルター処理される「拡張結合」のパフォーマンスが向上しました。拡張結合では、入力行ごとに複数の一致が生成され、大きな中間結果セットが作成されることがあります。これらの行の多くが後続のフィルターによって破棄されると、状況はさらに悪化します。9.2では、ルックアップデータにフィルターを適用するときに不要な行を除外することでこれらの結合を最適化し、破棄される行の処理を回避します。シナリオによっては、これらの結合は最大1000倍高速化される可能性があります。

この最適化は、ルックアップによって最初に多くの潜在的な一致が生成される可能性がある「拡張結合」を処理する場合に重要です。フィルターをインテリジェントにプッシュダウンすることで、関連するデータのみが処理され、クエリ実行時間が大幅に短縮され、膨大なデータセットでのリアルタイム分析が可能になります。つまり、非常に大規模または複雑な結合操作の場合でも、はるかに速く洞察を得ることができます。

Lookup Joinクラスター横断検索（CCS）の互換性：

8.19および9.1でLookup Joinが一般公開となった際、クロスクラスター検索（CCS）のサポートはありませんでした。複数のクラスターにまたがって運用している組織のため、LOOKUP JOINは9.2でCCSとシームレスに統合されるようになりました。ルックアップインデックスを結合したいすべてのリモートクラスターに配置するだけで、ES|QLは自動的にこれらのリモートルックアップインデックスを活用して、リモートデータと結合します。これにより、分散データ分析が簡素化され、Elasticsearch展開全体で一貫したエンリッチメントが保証されます。

これらの改善により、多様なデータセットを前例のない精度、速度、そして容易さで関連付けることができ、複雑な回避策や前処理のステップなしに、より深く、実用的な洞察を明らかにすることができます。

データを簡単に充実化：ルックアップインデックスのためのKibana Discoverユーザーエクスペリエンス

データのエンリッチメントはハードルではなく、シンプルであるべきです。KibanaのDiscoverに、ルックアップインデックスの作成と管理のための素晴らしい新しいユーザーエクスペリエンスを導入しました。

直感的なワークフロー：Discoverの包括的なオートコンプリートがES|QLエディターでルックアップインデックスや結合フィールドを提案するため、アップロードされたデータを既存のインデックスと驚くほど簡単に結びつけることができます。存在しないルックアップインデックスの名前を入力し、ワンクリックでルックアップエディターに直接アクセスしてインデックスを作成できます。既存の検索インデックスの名前を入力すると、編集オプションを提案します。

インライン管理（CRUD）： Discoverで直接、参照データセットをインライン編集機能（作成、読み取り、更新、削除）で最新の状態に保ちます。

簡単なファイルアップロード：CSVなどのファイルをDiscover内で直接アップロードし、 LOOKUP JOINですぐに使用できるようになりました。Kibanaのさまざまなエリアにジャンプしてコンテキストを切り替える必要はもうありません！

ユーザーIDを名前にマッピングしたり、ビジネスメタデータを追加したり、静的参照ファイルを結合したりする際、この特徴はデータのエンリッチメントを民主化し、結合のパワーをすべてのユーザーの手元に直接、迅速かつシンプルに、そして一箇所で提供します。

コンテキストの保持：INLINE STATSのご紹介（テクニカルプレビュー）

データの集約は重要ですが、時には集約を元のデータと並べて見る必要があることもあります。INLINE STATSをテクニカルプレビュー機能としてご紹介できることを嬉しく思います。

入力フィールドを集約された出力に置き換えるSTATSコマンドとは異なり、 INLINE STATS元の入力フィールドをすべて保持し、新しい集約されたフィールドを追加します。これにより、集計後に元の入力フィールドに対してさらに操作を実行できるようになり、より継続的で柔軟な分析ワークフローが実現します。

例えば、個々のフライトの行を保持しながら平均飛行距離を計算する場合：

FROM kibana_sample_data_flights
 | KEEP Carrier, Dest, DistanceMiles
 | INLINE STATS avgDist = ROUND(AVG(DistanceMiles))
       BY Dest
 | WHERE DistanceMiles > avgDist

このクエリでは、avgDistが各行に対応するDest(ination)と共に追加され、さらに、フライト情報の列が残っているため、平均を超える距離のフライトに結果をフィルタリングできます。

ES|QL における時系列サポート (技術プレビュー)

Elasticsearchは、メトリックを格納するために時系列データストリームを使用します。TSソースコマンドを通じて、ES|QLの時系列集計のサポートを追加しています。これは、Elastic Cloud Serverlessと9.2 basicでテクニカルプレビューとして利用できます。

時系列分析は主に、1つ以上のフィルタリングディメンションでスライスされた時間バケット全体のメトリック値を要約する集計クエリに基づいています。ほとんどの集計クエリは、(a) 時系列ごとに値を集計する内部集計関数と、(b) 時系列全体で (a) の結果を結合する外部集計関数という2段階の処理に依存しています。

TSソースコマンドをSTATSと組み合わせると、時系列にわたるこのようなクエリを簡潔かつ効果的に表現できるようになります。より具体的には、ホストおよび時間あたりのリクエストの合計レートを計算する次の例を考えてみましょう。

TS my_metrics
| WHERE @timestamp > NOW() - 1 day
| STATS SUM(RATE(requests))
      BY host, TBUCKET(1h)

この場合、時系列アグリゲーション関数 RATE はまず時系列と時間ごとに評価されます。生成された部分集計は、 SUMを使用して結合され、ホストおよび時間ごとの最終的な集計値が計算されます。

利用可能な時系列集計関数のリストはこちらで確認できます。カウンターを処理するための最も重要な集計関数のcounterレートがサポートされるようになりました。

TSソースコマンドはSTATSと組み合わせて使用するように設計されており、時系列集計を効率的にサポートするように実行が調整されています。例えば、データはSTATSに入る前にソートされます。処理コマンド（FORKやINLINE STATSなど）によって時系列データを強化または変更したり、その順序を変更したりすることは、現在TSとSTATSの間で許可されていません。この制限は将来解除される可能性があります。

STATS表形式の出力は、適用可能なコマンドを使用してさらに処理できます。例えば、以下のクエリは、ホストごとの平均の cpu_usage と時間の比率とホストごとの最大値の比率を計算します。

TS my_metrics
| STATS avg_usage = AVG(AVG_OVER_TIME(cpu_usage))
      BY host, time_bucket = TBUCKET(1h)
| INLINE STATS max_avg_usage = MAX(avg_usage)
      BY host
| EVAL ratio = avg_usage / max_avg_usage
| KEEP host, time_bucket, ratio
| SORT host, time_bucket DESC

時系列データは、Luceneドキュメント値を利用した基盤となる列指向ストレージエンジンに保存されます。TSコマンドは、ES|QLコンピュートエンジンを介してベクトル化されたクエリの実行を追加します。クエリパフォーマンスは、同等のDSLクエリと比較して、しばしば1桁以上の向上が見られ、確立されたメトリクス固有のシステムと同等になります。今後、詳細なアーキテクチャおよびパフォーマンス分析も提供する予定ですので、どうぞご期待ください。

ツールキットの拡張：新しい ES|QL関数

文字列操作：INCLUDES、MV_CONTAINS、URL_ENCODE、 URL_ENCODE_COMPONENT、URL_DECODEが追加され、より堅牢なテキストおよびURL処理を実現します。

時系列と地理空間:柔軟な時間バケツ処理のためのTBUCKET 、ベクトル演算のための TO_DENSE_VECTOR、高度な位置ベースの分析のためのST_GEOHASH 、 ST_GEOTILE 、 ST_GEOHEX 、 TO_GEOHASH 、 TO_GEOTILE 、 TO_GEOHEXなどの包括的な地理空間関数のセット。

日付のフォーマット：DAY_NAME、MONTH_NAMEは、より読みやすい日付表現のために使用されます。

これらの関数には、ES|QL内で直接データを操作および分析するための豊富なツールセットが用意されています。

内部の改善：パフォーマンスと効率性の向上

注目の機能以外にも、Elasticsearch 9.2にはES|QL全体にわたる数多くのパフォーマンス最適化が含まれています。関数が複数の類似したRLIKEクエリを置き換える場合に、プッシュダウンを使用してRLIKE (LIST) を高速化しました。RLIKE (LIST) を使用すると、これらのクエリを1つのオートマトンに結合し、複数ではなく1つのオートマトンを適用できます。また、インデックスの並べ替えによるキーワードフィールドの読み込みが高速化され、クエリ全般が最適化されました。これらの改善により、ES|QLクエリがこれまで以上に効率的に実行されるようになります。

今すぐ始めましょう！

Elasticsearch 9.2は、ES|QLを大きく飛躍させ、データ分析ワークフローにかつてないパワーと柔軟性をもたらします。ぜひこれらの新機能を試して、その違いを体験してください。

Elasticsearch 9.2のすべての変更点と機能強化の包括的なリストについては、公式リリースノートを参照してください。楽しいクエリングを!

カスタムコネクターを使用すると、既存の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トークンの取得

1. ngrokで無料アカウントに登録します。
2. ngrokダッシュボードにアクセスします。
3. 認証トークンをコピーします。

Google Colabにシークレットを追加する

Google Colabノートブック内で：

1. 左側のサイドバーにあるキーアイコンをクリックして、シークレットを開きます。
2. 次の3つのシークレットを追加します。

ELASTICSEARCH_URL=https://your-cluster.elastic.com:443
ELASTICSEARCH_API_KEY=your-api-key
NGROK_TOKEN=your-ngrok-token

3. 各シークレットのノートブックアクセスを有効にします。

ステップ3：ノートブックを実行する

1. ランタイムをクリックし、次にすべて実行をクリックして、すべてのセルを実行します。
2. サーバーの起動を待ちます（約30秒）。
3. 公開ngrok URLを示す出力を探します。

4. 出力は次のようになります。

ChatGPTに接続する

次に、MCPサーバーをあなたのChatGPTアカウントに接続します。

1. ChatGPTを開き、設定に移動します。
2. コネクターに移動します。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の詳細を教えて」

1. ChatGPT呼び出し fetch(“ISSUE-1889”)
2. Elasticsearchが完全な文書を取得する
3. すべてのフィールドがルートレベルにある完全な文書を返す
4. ChatGPTは情報を統合し、適切な引用で回答する

まとめ

この記事では、専用の検索およびフェッチMCPツールを使用してChatGPTをElasticsearchに接続するカスタムMCPサーバーを構築し、プライベートデータに対する自然言語クエリを可能にしました。

このMCPパターンは、自然言語を使用してクエリしたい任意のElasticsearchインデックス、ドキュメント、製品、ログ、またはその他のデータで機能します。

エージェント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. 順次取得チェーン: 順次ワークフローは、複雑なタスクを単純な順序付けられたステップに分割します。各ステップで次のステップの入力が改善され、より良い結果が得られます。たとえば、顧客プロファイルを作成する場合、1 人のエージェントが CRM から基本的な詳細を取得し、別のエージェントがトランザクション データベースから購入履歴を取得し、最後のエージェントがこの情報を組み合わせて推奨事項やレポート用の完全なプロファイルを生成します。
2. ルーティング取得チェーン: このワークフロー パターンでは、ルーター エージェントが入力を分析し、最も適切なプロセスまたはデータ ソースに送信します。このアプローチは、重複が最小限で複数の異なるデータ ソースが存在する場合に特に効果的です。たとえば、顧客サービス システムでは、ルータ エージェントが技術的な問題、払い戻し、苦情などの受信リクエストを分類し、適切な部門にルーティングして効率的に処理します。
3. 並列検索チェーン: このワークフロー パターンでは、複数の独立したサブタスクが同時に実行され、それらの出力が後で集約されて最終的な応答が生成されます。このアプローチにより、処理時間が大幅に短縮され、ワークフローの効率が向上します。たとえば、顧客サービスの並列ワークフローでは、1 人のエージェントが過去の同様のリクエストを取得し、別のエージェントが関連するナレッジベースの記事を参照します。アグリゲータはこれらの出力を組み合わせて包括的な解決策を生成します。
4. オーケストレーター ワーカー チェーン: このワークフローは、独立したサブタスクを利用するため、並列化と類似点があります。ただし、重要な違いはオーケストレーター エージェントの統合にあります。このエージェントは、ユーザークエリを分析し、実行時にそれらをサブタスクに動的に分割し、正確な応答を作成するために必要な適切なプロセスまたはツールを識別する役割を担います。

エージェント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 チャンネルやディスカッション フォーラムを通じてご連絡いただくこともできます。

各種資料

• セルフRAG：自己反省を通して、情報の検索、生成、批評を学ぶ
• エージェント検索拡張生成：エージェントRAGの調査

スコア範囲の問題

まず最初に、ハイブリッド検索が困難になる主な理由の 1 つである、スコア範囲の多様性について確認しましょう。私たちの古い友人BM25は無制限のスコアを生成します。言い換えれば、BM25 は 0 に近い値から (理論的には) 無限大までの範囲のスコアを生成できます。対照的に、 dense_vectorフィールドに対するクエリでは、0 から 1 の範囲のスコアが生成されます。この問題をさらに悪化させるのは、 semantic_text埋め込みのインデックス作成に使用されるフィールド タイプが難読化されるため、インデックスと推論エンドポイントの構成に関する詳細な知識がない限り、クエリのスコアの範囲がどうなるかを判断するのが難しい場合があることです。これは、語彙検索結果と意味検索結果をインターリーブしようとするときに、意味検索結果の関連性が高い場合でも、語彙検索結果が意味検索結果よりも優先される可能性があるため、問題が発生します。この問題に対する一般的に受け入れられている解決策は、結果をインターリーブする前にスコアを正規化することです。Elasticsearch には、これを実行するためのツールとして、線形リトリーバーとRRFリトリーバーの 2 つがあります。

RRFリトリーバーは、ドキュメントのランクを関連性の尺度として使用し、スコアを破棄して、 RRF アルゴリズムを適用します。スコアは考慮されないため、スコア範囲の不一致は問題になりません。

線形リトリーバーは線形結合を使用してドキュメントの最終スコアを決定します。これには、ドキュメントの各コンポーネント クエリのスコアを取得し、それを正規化し、合計して合計スコアを生成することが含まれます。数学的には、この操作は次のように表現できます。

Total Score = 𝚺(N(Sx))

ここで、 Nは正規化関数であり、SX はクエリ X のスコアです。ここで重要なのは正規化関数です。正規化関数は各クエリのスコアを同じ範囲を使用するように変換します。リニア リトリーバーの詳細については、こちらをご覧ください。

詳しく見てみる

ユーザーはこれらのツールを使用して効果的なハイブリッド検索を実装できますが、インデックスに関するある程度の知識が必要です。線形リトリーバーを使用して、2 つのフィールドを持つインデックスをクエリする例を見てみましょう。

PUT linear_retriever_example
{
  "mappings": {
    "properties": {
      "semantic_text_field": { <1>
        "type": "semantic_text",
        "inference_id": ".multilingual-e5-small-elasticsearch"
      },
      "text_field": { <2>
        "type": "text"
      }
    }
  }
}

1. semantic_text_fieldは、テキスト埋め込みモデルであるE5を使用するsemantic_textフィールドです。

2. text_fieldは標準のtextフィールドです

GET linear_retriever_example/_search
{
  "retriever": {
    "linear": {
      "retrievers": [
        {
          "retriever": {
            "standard": {
              "query": {
                "match": { <1>
                  "semantic_text_field": "foo"
                }
              }
            }
          },
          "normalizer": "minmax"
        },
        {
          "retriever": {
            "standard": {
              "query": {
                "match": {
                  "text_field": "foo"
                }
              }
            }
          },
          "normalizer": "minmax"
        }
      ]
    }
  }
}

1. Elasticsearch 8.18/9.0でサポートされたsemantic_textフィールドでmatchクエリを使用します。

クエリを構築するときは、 semantic_text_fieldテキスト埋め込みモデルを使用するため、このクエリでは 0 から 1 の間のスコアが生成されることに留意する必要があります。また、 text_fieldは標準のtextフィールドであるため、これに対するクエリによって無制限のスコアが生成されることも知っておく必要があります。適切な関連性を持つ結果セットを作成するには、クエリ スコアを結合する前に正規化するリトリーバーを使用する必要があります。この例では、 minmax正規化を備えた線形リトリーバーを使用して、各クエリのスコアを 0 から 1 の間の値に正規化します。

この例のクエリ構築は、関係するフィールドが 2 つだけなので、非常に簡単です。ただし、さまざまなタイプのフィールドが追加されると、すぐに複雑になる可能性があります。これは、効果的なハイブリッド検索クエリを記述するには、クエリ対象のインデックスに関するより深い知識が必要になることが多く、組み合わせる前にコンポーネント クエリ スコアが適切に正規化される必要があることを示しています。これは、ハイブリッド検索のより広範な導入の障害となります。

クエリのグループ化

例を拡張してみましょう。1 つのtextフィールドと 2 つのsemantic_textフィールドをクエリしたい場合はどうなるでしょうか。次のようなクエリを作成できます。

GET linear_retriever_example/_search
{
  "retriever": {
    "linear": {
      "retrievers": [
        {
          "retriever": {
            "standard": {
              "query": {
                "semantic": {
                  "field": "semantic_text_field_1",
                  "query": "foo"
                }
              }
            }
          },
          "normalizer": "minmax"
        },
        {
          "retriever": {
            "standard": {
              "query": {
                "semantic": {
                  "field": "semantic_text_field_2",
                  "query": "foo"
                }
              }
            }
          },
          "normalizer": "minmax"
        },
        {
          "retriever": {
            "standard": {
              "query": {
                "match": {
                  "text_field": "foo"
                }
              }
            }
          },
          "normalizer": "minmax"
        }
      ]
    }
  }
}

表面的には良さそうですが、潜在的な問題があります。これで、 semantic_textフィールドの一致が合計スコアの 2/3 を占めることになります。

Total Score = N(semantic_text_field_1 score) + N(semantic_text_field_2 score) + N(text_field score)

これは、不均衡なスコアを作成するため、おそらく望ましい結果ではありません。この例のようにフィールドが 3 つしかない場合、影響はそれほど顕著ではないかもしれませんが、より多くのフィールドをクエリすると問題が生じます。例えば、ほとんどの索引には意味フィールド（つまりdense_vector 、 sparse_vector 、またはsemantic_text )。上記のパターンを使用して、9 つの語彙フィールドと 1 つの意味フィールドを持つインデックスをクエリするとどうなるでしょうか?語彙の一致がスコアの 90% を占めることになり、意味検索の有効性が鈍ってしまいます。

これに対処する一般的な方法は、クエリを語彙と意味のカテゴリにグループ化し、その 2 つに均等に重み付けすることです。これにより、どちらかのカテゴリーが合計スコアを支配することが防止されます。

それを実践してみましょう。この例では、線形リトリーバーを使用する場合、グループ化されたクエリのアプローチはどのようになるでしょうか?

GET linear_retriever_example/_search
{
  "retriever": {
    "linear": {
      "retrievers": [
        {
          "retriever": {
            "linear": {
              "retrievers": [
                {
                  "retriever": {
                    "standard": {
                      "query": {
                        "semantic": {
                          "field": "semantic_text_field_1",
                          "query": "foo"
                        }
                      }
                    }
                  },
                  "normalizer": "minmax"
                },
                {
                  "retriever": {
                    "standard": {
                      "query": {
                        "semantic": {
                          "field": "semantic_text_field_2",
                          "query": "foo"
                        }
                      }
                    }
                  },
                  "normalizer": "minmax"
                }
              ]
            }
          },
          "normalizer": "minmax"
        },
        {
          "retriever": {
            "standard": {
              "query": {
                "match": {
                  "text_field": "foo"
                }
              }
            }
          },
          "normalizer": "minmax"
        }
      ]
    }
  }
}

うわー、これは冗長になってきましたね!クエリ全体を確認するには、上下に何度もスクロールする必要があったかもしれません。ここでは、2 つのレベルの正規化を使用してクエリ グループを作成します。数学的には次のように表現できます。

Total Score = N(N(semantic_text_field_1 score) + N(semantic_text_field_2 score)) + N(text_field score)

この 2 番目のレベルの正規化により、 semantic_textフィールドとtextフィールドに対するクエリが均等に重み付けされるようになります。この例では、語彙フィールドが 1 つしかないため、 text_fieldの 2 番目のレベルの正規化を省略し、冗長性をさらに軽減していることに注意してください。

このクエリ構造はすでに扱いにくく、クエリするフィールドは 3 つだけです。より多くのフィールドをクエリするにつれて、熟練した検索実践者にとっても管理がますます困難になります。

複数フィールドのクエリ形式

これらすべてを簡素化するために、Elasticsearch 8.19、9.1、 サーバーレスの 線形および RRF リトリーバーに マルチフィールド クエリ形式 を追加しました。次のようにするだけで、上記と同じクエリを実行できます。

GET linear_retriever_example/_search
{
  "retriever": {
    "linear": {
      "fields": [ "semantic_text_field_1", "semantic_text_field_2", "text_field" ],
      "query": "foo",
      "normalizer": "minmax"
    }
  }
}

これにより、クエリが 55 行から 9 行に短縮されます。Elasticsearch はインデックス マッピングを自動的に使用して次の処理を実行します。

• クエリされた各フィールドのタイプを決定する
• 各フィールドを語彙または意味のカテゴリにグループ化します
• 最終スコアでは各カテゴリーを均等に重み付けする

これにより、使用されるインデックスや推論エンドポイントの詳細を知らなくても、誰でも効果的なハイブリッド検索クエリを実行できるようになります。

RRF を使用する場合、ランクは関連性の代理として使用されるため、 normalizerを省略できます。

GET rrf_retriever_example/_search
{
  "retriever": {
    "rrf": {
      "fields": [ "semantic_text_field_1", "semantic_text_field_2", "text_field" ],
      "query": "foo"
    }
  }
}

フィールドごとのブースティング

リニア リトリーバーを使用する場合、フィールドごとにブーストを適用して、特定のフィールドでの一致の重要度を調整できます。たとえば、2 つのsemantic_textフィールドと 2 つのtextフィールドの 4 つのフィールドをクエリするとします。

GET linear_retriever_example/_search
{
  "retriever": {
    "linear": {
      "fields": [ "semantic_text_field_1", "semantic_text_field_2", "text_field_1", "text_field_2" ],
      "query": "foo",
      "normalizer": "minmax"
    }
  }
}

デフォルトでは、各フィールドはグループ内（語彙または意味）で均等に重み付けされます。スコアの内訳は次のようになります。

つまり、各フィールドは合計スコアの 25% を占めます。

field^boost構文を使用して、任意のフィールドにフィールドごとのブーストを追加できます。semantic_text_field_1とtext_field_1に2のブーストを適用してみましょう。

GET linear_retriever_example/_search
{
  "retriever": {
    "linear": {
      "fields": [ "semantic_text_field_1^2", "semantic_text_field_2", "text_field_1^2", "text_field_2" ]
      "query": "foo",
      "normalizer": "minmax"
    }
  }
}

スコアの内訳は次のようになります。

各クエリ グループの重みは均等ですが、グループ内のフィールドの重みは次のように変更されました。

• semantic_text_field_1 セマンティッククエリグループスコアの66％、合計スコアの33％
• text_field_1 語彙質問グループスコアの66％、総スコアの33％

ワイルドカード解決

複数のフィールドを一致させるには、 fieldsパラメータで*ワイルドカードを使用できます。上記の例を続けると、このクエリは機能的にはemantic_text_field_1 、 semantic_text_field_2 、 text_field_1明示的にクエリすることと同等です。

GET linear_retriever_example/_search
{
  "retriever": {
    "linear": {
      "fields": [ "semantic_text_field_*", "*_field_1" ],
      "query": "foo",
      "normalizer": "minmax"
    }
  }
}

興味深いことに、 *_field_1パターンはtext_field_1とsemantic_text_field_1の両方に一致します。これは自動的に処理され、各フィールドが明示的にクエリされたかのようにクエリが実行されます。semantic_text_field_1が両方のパターンに一致することも問題ありません。すべてのフィールド名の一致は、クエリの実行前に重複が排除されます。

ワイルドカードはさまざまな方法で使用できます。

• プレフィックス一致（例： *_text_field ）
• インラインマッチング（例： semantic_*_field ）
• サフィックス一致（例： semantic_text_field_* ）

*_text_field_*のように、複数のワイルドカードを使用して上記の組み合わせを適用することもできます。

デフォルトのクエリフィールド

マルチフィールド クエリ形式を使用すると、何も知らないインデックスをクエリすることもできます。fieldsパラメータを省略すると、 index.query.default_field インデックス設定で指定されたすべてのフィールドがクエリされます。

GET linear_retriever_example/_search
{
  "retriever": {
    "linear": {
      "query": "foo",
      "normalizer": "minmax"
    }
  }
}

デフォルトでは、 index.query.default_fieldは*に設定されています。このワイルドカードは、用語クエリをサポートするインデックス内のすべてのフィールド タイプ (ほとんど) に解決されます。例外は次のとおりです:

• dense_vector フィールド
• rank_vector フィールド
• ジオメトリフィールド: geo_point 、 shape

この機能は、サードパーティが提供するインデックスに対してハイブリッド検索クエリを実行する場合に特に便利です。マルチフィールド クエリ形式を使用すると、適切なクエリを簡単な方法で実行できます。fieldsパラメータを除外するだけで、該当するすべてのフィールドが照会されます。

まとめ

スコア範囲の問題により、特にクエリ対象のインデックスや使用中の推論エンドポイントに関する情報が限られている場合、効果的なハイブリッド検索の実装が困難になる可能性があります。リニア リトリーバーと RRF リトリーバーのマルチフィールド クエリ形式では、自動化されたクエリ グループ化ベースのハイブリッド検索アプローチをシンプルで使いやすい API にパッケージ化することで、この煩わしさを軽減します。フィールドごとのブースト、ワイルドカード解決、デフォルトのクエリ フィールドなどの追加機能により、機能が拡張され、多くのユース ケースをカバーできます。

今すぐマルチフィールドクエリ形式をお試しください

無料トライアル では、完全に管理された Elasticsearch Serverless プロジェクトで、マルチフィールド クエリ形式を使用した線形リトリーバーと RRF リトリーバーを試すことができます。8.19 および 9.1 以降のスタック バージョンでも利用できます。

1 つのコマンドでローカル環境で数分以内に開始できます。

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

この記事では、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 つのステップに分けられます。

1. ローカルモデルでLMスタジオを構成する
2. DockerでローカルElasticをデプロイする
3. ElasticでOpenAIコネクタを作成する
4. 従業員データをElasticsearchにアップロードする
5. AIエージェントを構築してテストする

ステップ1：LM StudioをGPT-OSS 20Bで構成する

LM Studio は、大規模な言語モデルをコンピュータ上でローカルに実行できるユーザーフレンドリーなアプリケーションです。OpenAI 互換の API サーバーを提供するため、複雑なセットアップ プロセスなしで Elastic などのツールと簡単に統合できます。詳細については、 LM Studio ドキュメントを参照してください。

まず、公式サイトからLM Studioをダウンロードしてインストールします。インストールしたら、アプリケーションを開きます。

LM Studio インターフェースの場合:

1. 検索タブに移動して「GPT-OSS」を検索します。
2. OpenAIからopenai/gpt-oss-20bを選択してください
3. ダウンロードをクリック

このモデルのサイズは約12.10 GBになります。インターネット接続によっては、ダウンロードに数分かかる場合があります。

モデルをダウンロードしたら:

1. ローカルサーバータブに移動します
2. openai/gpt-oss-20bを選択します
3. デフォルトのポート1234を使用する
4. 右側のパネルで、 「ロード」に移動し、コンテキストの長さを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 を構成します。

アクセスコネクタ

1. キバナで
2. プロジェクト設定>管理に移動します
3. アラートとインサイトの下で、コネクタを選択します。
4. コネクタの作成をクリック

コネクタを構成する

コネクタのリストから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 設定」に移動し、作成した設定を選択して「保存」をクリックします。

アクセスエージェントビルダー

1. エージェントへ
2. 「新しいエージェントを作成」をクリックします

エージェントを構成する

新しいエージェントを作成するには、エージェント 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 の公式ドキュメントを参照してください。

数週間前、私たちは、世界中から 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 エージェント ニュースルームを作成する」の補足記事です。この記事では、同じエージェント内に 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 ワークフローの完全なシーケンスです。

まとめ

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

検索は死んでいない、ただ移動しただけだ

そのため、主にテキスト ボックスでコンテキストを検索し、返された情報 (コンテキスト) を使用して自分で回答を構築するという方法から、自然言語を使用してエージェントに必要なものを伝え、エージェントが自動的に回答を調査してまとめる方法へと移行しました。テクノロジー業界の多くの人々は、この変化を指摘し、「検索は死んだ」と主張しています（まあ、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を使用して各フォークの結果をマージします)。架空の製品検索の簡単な例を次に示します。

FROM products
| FORK
  (MATCH description "high performance gaming laptop" | EVAL search_type = "bm25"),
  (MATCH description_semantic "high performance gaming laptop" | EVAL search_type = "semantic")
| FUSE 
| LIMIT 20
| KEEP product_name, description, _score, search_type

上記の例の各 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を意味します。

データと対話する新しい方法

ジェネレーティブ (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 へ進みます: コンテキスト エンジニアリングにおけるハイブリッド検索の威力!

ECK はマーケットプレイスベースの Elastic Cloud ソリューションよりも大幅に多くの労力を必要としますが、Kubernetes オペレーターがシステム オーケストレーションとノードのスケーリングを処理するため、VM を自分でデプロイするよりも自動化されています。

今回は、Automatic を使用して Azure Kubernetes Service (AKS) を操作します。他の記事では、 Azure VMとAzure Marketplace の使用方法について学習します。

AKS Automatic とは何ですか?

Azure Kubernetes Service (AKS) は、クラスターのセットアップを自動的に管理し、リソースを動的に割り当て、Kubernetes の柔軟性を維持しながらセキュリティのベスト プラクティスを統合するため、開発者はコンテナー イメージからデプロイされたアプリケーションまでを数分以内に実行できます。

AKS Automatic は、クラスター管理のオーバーヘッドの大部分を排除し、シンプルさと柔軟性のバランスを適切にとります。適切な選択はユースケースによって異なりますが、次のことを計画すると決定が容易になります。

• テスト環境をデプロイする:デプロイは高速かつ簡単なので、簡単な実験や短期間のクラスターに最適です。
• 厳密な VM、ストレージ、またはネットワーク要件なしで作業: AKS Automatic では定義済みのデフォルトが提供されるため、それがニーズに合えば、追加の構成を行う必要がなくなります。
• Kubernetes を初めて使用する場合: AKS Automatic はクラスターのセットアップの大部分を処理するため、学習曲線が短縮され、チームはアプリケーションに集中できるようになります。

Elasticsearch では、Elastic Stack の Kubernetes デプロイメント オーケストレーションを簡素化する公式 Elastic Kubernetes オペレーターであるElastic Cloud on Kubernetes (ECK) を使用します。

AKS Automaticの設定方法

1. Microsoft Azure ポータルにログインします。

2.右上の Cloud Shellボタンをクリックし、コンソールにアクセスしてそこから AKS クラスターをデプロイします。あるいは、 Azure Cloud Shell を使用することもできます。

チュートリアル中にプロジェクト ID を自分のものに更新することを忘れないでください。

AKS を開くと、上のスクリーンショットのようになります。

3. aks-preview Azure CLI 拡張機能をインストールします。このプレビュー バージョンでは、クラスターの作成時に--sku automaticを選択できるようになり、AKS Automatic 機能が有効になります。

az extension add --name aks-preview

このメッセージが表示された場合、AKS 拡張機能が正しくインストールされたことを意味します。

4. az feature registerコマンドを使用して機能フラグを登録する

az feature register --namespace Microsoft.ContainerService --name AutomaticSKUPreview

作成した機能サブスクリプションの詳細が表示されます。

登録ステータスが「登録中」から「登録済み」に変わるまで確認します。登録が完了するまでに数分かかる場合があります。

az feature show --namespace Microsoft.ContainerService --name AutomaticSKUPreview

変更を伝播するにはaz provider registerを実行します。

az provider register --namespace Microsoft.ContainerService

5. リソースグループを作成する

リソース グループは、管理およびデプロイされる Azure リソースの論理グループです。

az group create --name elastic-resource --location eastus

6. Autopilot クラスターを作成します。これをmyAKSAutomaticCluster に名前を付け、先ほど作成したリソース グループを使用します。AKS がリソースを割り当てるには、 Standard_D4pds_v5 、 Standard_D4lds_v5 、 Standard_D4ads_v5 、 Standard_D4ds_v5 、 Standard_D4d_v5 、 Standard_D4d_v4 、 Standard_DS3_v2 、 Standard_DS12_v2 のいずれかの VM サイズで 16 個の vCPU が使用可能であることを確認してください。

az aks create \
    --resource-group elastic-resource \
    --name myAKSAutomaticCluster \
    --sku automatic \
    --generate-ssh-keys

* MissingSubscriptionRegistrationエラーが発生した場合は、不足しているサブスクリプションを使用して手順4に戻ってください。たとえば、 The subscription is not registered to use namespace ' microsoft.insights '実行中のサブスクリプションが必要です。az provider register --namespace Microsoft.Insights.

対話型ログインに従ってください:

「az login」の実行を求めるメッセージが表示されます。そのコマンドを実行してから待つ必要があります。

7. 準備ができるまで待ちます。作成には約10分かかります。

8. kubectl コマンドライン アクセスを構成します。

az aks get-credentials --resource-group elastic-resource --name myAKSAutomaticCluster

インストールした拡張機能によって AKS Automatic が有効になっていることに注意してください。

9. ノードがデプロイされたことを確認します。

kubectl get nodes

禁止エラー メッセージが表示されます。エラーからユーザー ID をコピーします。

10. ユーザーを AKS アクセス制御に追加します。

AKS ID を取得します。コマンドからの出力をコピーします。

az aks show --resource-group elastic-resource  --name myAKSAutomaticCluster --query id --output tsv

AKS ID とユーザーのプリンシパル ID を使用してロールの割り当てを作成します。

az role assignment create --role "Azure Kubernetes Service RBAC Cluster Admin" --assignee  --scope 

11. ノードが再度デプロイされたことを確認します。

kubectl get nodes

12. Kubernetes (ECK) オペレーターに Elastic Cloud をインストールします。

# Install ECK Custom Resource Definitions
kubectl create -f https://download.elastic.co/downloads/eck/2.16.1/crds.yaml

# Install the ECK operator
kubectl apply -f https://download.elastic.co/downloads/eck/2.16.1/operator.yaml

13. デフォルト値を使用して、単一ノードの Elasticsearch インスタンスを作成しましょう。

cat <

デフォルトの AKS マシンのvm.max_map_count値が低すぎるため、 nmapを無効にしました。本番環境では無効にすることは推奨されませんが、 vm.max_map_countの値を増やすことは推奨されます。これを行う方法の詳細については、ここを参照してください。

14. Kibana シングルノード クラスターもデプロイしましょう。Kibana の場合は、ロード バランサーを追加します。これにより、デバイスから Kibana にアクセスするために使用できる外部 IP が提供されます。

cat <

デフォルトでは、AKS Automatic はロード バランサーをパブリックとして構成します。メタデータ アノテーションを設定することで動作を変更できます。

service.beta.kubernetes.io/azure-load-balancer-internal: "true"

15. ポッドが実行中であることを確認します。

kubectl get pods

16.Elasticsearch のバージョン、ノード、健全性などのより具体的な統計情報を取得するには、 kubectl get elasticsearchとkubectl get kibanaを実行することもできます。

17. サービスにアクセスします。

kubectl get svc

これにより、EXTERNAL-IP の下に Kibana の外部 URLが表示されます。ロードバランサーのプロビジョニングには数分かかる場合があります。EXTERNAL-IP の値をコピーします。

18. 'elastic' ユーザーの Elasticsearch パスワードを取得します。

kubectl get secret quickstart-es-elastic-user -o=jsonpath='{.data.elastic}' | base64 --decode

19. ブラウザからKibana にアクセスします。

a. URL: https://<EXTERNAL_IP>:5601

b. ユーザー名:elastic

c. パスワード:c44A295CaEt44D6xIzN6Zs5m (前の手順から)

20.ブラウザから Elastic Cloud にアクセスすると、ようこそ画面が表示されます。

ノードの変更やサイズ変更など、Elasticsearch クラスターの仕様を変更する場合は、新しい設定で YML マニフェストを再度適用できます。

cat <

この例では、さらに 1 つのノードを追加し、RAM と CPU を変更します。ご覧のとおり、 kubectl get elasticsearchには 2 つのノードが表示されています。

Kibana にも同じことが当てはまります。

cat <

コンテナのCPU/RAMとNode.jsのメモリ使用量（ max-old-space-size ）を調整できます。

既存のボリュームクレームを縮小することはできないことに留意してください。アップデートを適用した後、オペレーターは最小限の中断時間で変更を加えます。

不要なコストを避けるために、テストが完了したらクラスターを忘れずに削除してください。

az aks delete --name myAKSAutomaticCluster --resource-group elastic-resource

まとめ

Azure AKS Automatic を ECK と併用すると、Elasticsearch と Kibana をデプロイするためのバランスの取れたソリューションが提供されます。これにより、運用の複雑さが軽減され、スケーリングと更新が自動化され、Kubernetes の柔軟性が活用されます。このアプローチは、インフラストラクチャの詳細をすべて手動で管理することなく、信頼性が高く、繰り返し可能で、保守可能なデプロイメント プロセスを求めるチームに最適であり、テスト環境と本番環境の両方にとって実用的な選択肢となります。

今後の見通し

Kubernetes について詳しく知りたい場合は、次の公式ドキュメントをご覧ください。

• Kubernetes 上の Elastic Cloud | Elastic ドキュメント
• Azure Kubernetes Service (AKS) Automatic (プレビュー) の概要
• AKS Automatic - AKSエンジニアリングブログ

]]>