新規ユーザーにとって、これは高品質なベクトル検索を最も迅速に開始する方法です。すでにElasticsearchをご利用の場合は、新しいシステムを導入する必要はなく、データが既に存在するプラットフォーム上でベクトル検索を利用できるようになります。Elasticsearch Vector Databaseは、大規模言語モデル（LLM）のグラウンディングから、AIエージェントへの検索機能とメモリの提供、数千億ものベクトルの提供まで、幅広いシナリオをサポートします。わずか数分で新しいプロジェクトを立ち上げ、開始できます。

1つのエンジン、あらゆるベクトルユースケース

Elasticsearch Vector Databaseは、ベクトルを使用してアプリケーションを構築するすべての人向けに設計されています。

• RAG：高密度ベクトル検索と低密度ベクトル検索でLLMに最適なコンテキストを取得するか、ベクトル検索と語彙検索の両方を組み合わせたハイブリッド検索を利用できます。生成結果の質は、検索結果の質に比例して向上します。

• AIエージェント：マルチステップのエージェントループで求められる低レイテンシで、ドキュメントや会話記憶に対する高速でフィルタリングされた検索をエージェントに提供します。

• セマンティック検索：1つのフィールドタイプとパイプラインコード不要で、キーワードではなく意味に基づいて一致させます。

• レコメンデーションと類似性：製品、画像、その他あらゆるコンテンツにわたり、大規模なスケールで最近傍を検索できます。

ベクトルワークロードに必要なすべてを、すぐに使えるよう最適化

ベクトルベースのアプリケーションを構築するには、いくつかの個別の要素を連携させる必要があります。具体的には、埋め込みモデルの設定とホスティング、それらを用いたドキュメントのインデックス作成、ベクトルの効率的な保存、各クエリへの埋め込みモデルの適用、ベクトルストアとの照合、そして最後に、一致したドキュメントの取得です。Elasticsearch Vector Databaseは、追加の設定やセットアップなしで、これらすべてを自動的に処理します。

vectordb_documentインデックスモードを使用したベクトルのインデキシング

ベクトル優先ワークロード専用に設計された新しいインデックス構成であるvectordb_documentインデックスモードはデフォルトで有効になっており、エキスパートが選択するような設定が適用されます。以下が有効化されます。

• デフォルトでbfloat16：ベクトルはfloat32の半分のサイズで格納され、再現率への影響はごくわずかで、量子化を適用する前の段階でもディスク使用量をほぼ半分に削減します。

• ソースベクトルの除外：Elasticsearchでは、埋め込みはすでに検索に使用されるインデックス構造内に存在します。_sourceに未加工のコピーを重複して保持すると、ストレージを消費し、結果の取得が遅くなるだけです。重複を除外することで、レスポンスが高速化され、格納するデータ量を削減できます。

• 適切なファイルをキャッシュに事前読み込み：ベクトルクエリが最初にアクセスするデータ構造があらかじめメモリに読み込まれるされるため、1番目の（そして1,000番目の）クエリも超高速で実行されます。

• 並列マージ：マージによってセグメントがより整理されたベクトル構造に統合され、再現率とレイテンシーの両方が向上します。さらに、これらのマージをマルチスレッドで実行することで、より高速に完了できます。

ベクトルストレージ、圧縮、自動チューニング

• ベクトルは自動的に圧縮されます。Better Binary Quantization（BBQ）により、再現率を維持しながらベクトルのメモリ・フットプリントを最大32倍削減できます。さらに、DiskBBQは大規模なワークロードのメモリ要件をさらに削減します。 

• 自動キャリブレーションを有効にすると、各セグメントの量子化がデータに合わせて調整され、データのずれに応じてマージのたびに再調整されます。18種類のデータセットでテストを行った結果、1秒あたりのクエリ数（QPS）は平均16.7%向上し、そのほとんどで再現率も向上しました。

マネージドGPU推論での埋め込み

• ネイティブのJina AIの埋め込みモデルとリランカーモデルで埋め込みを生成することも、サードパーティ製モデルを導入することもできます。いずれもElastic Inference Service（EIS）を介したマネージドGPUで実行でき、モデルサーバーを運用する必要はありません。または、ご自身でホストすることも可能です。

• semantic_textフィールドタイプは、チャンキングと埋め込み、そしてクエリを自動的に処理し、市場で最もシンプルなセマンティック検索への道を提供します。

ハイブリッド検索とフィルタリングされたベクトル検索

• ハイブリッド検索が組み込まれており、単一のクエリで全文検索とベクトル検索を組み合わせることができます。逆順位融合（RRF）やその他の任意のブレンドメカニズムを使用して結果を統合できます。通常、ベクトル検索はハイブリッド検索の中で適切に設定するのが最も難しい部分です。Elasticsearch Vector Databaseを使用すれば、その問題は解決し、ハイブリッドスタック全体の性能が向上します。

• フィルタリングされたベクトル検索では、再現率を損なう後処理としてではなく、ベクトル検索自体の一部としてメタデータフィルタを適用できます。

初日からエンタープライズ対応

また、純粋なベクトルデータベースには一般的に備わっていない、ロールベースのアクセス制御（RBAC）、監査ログ、コンプライアンス認定も利用できます。

スケールしても手頃で予測可能

Elasticsearch Vector Databaseは、成長に合わせてコスト効率を維持できるように設計されています。ストレージを線形に保ち、メモリ使用量を低く抑えるBBQおよびDiskBBQ圧縮により、数千億のベクトルに拡張してもコストが急増することはありません。支払う料金は、格納するデータ量、作成するインデックス量、必要な検索容量など、すでに把握している数値に基づいて算出されます。ドキュメント数、ベクトルの次元数、クエリ負荷を見積もれば、プロジェクトを作成する前に料金を算出できます。月末には、請求内容を項目ごとに確認することもできます。不透明な計算ユニットはなく、バックグラウンド処理に対する予期せぬ料金も発生しません。

Elasticsearch Vector Databaseの利用開始方法

サーバーレスベクトルデータベースプロジェクトを作成する

Elastic Cloudで新しいサーバーレスVector Databaseプロジェクトを作成します。データをエンドポイントに向ければ、インデックスの準備は完了です。

semantic_textを使用したインデックスの作成

ベクトルインデックスモードは、ベクトルの構成を処理します。semantic_textを使用すると、マネージドGPU推論上でインデックス設定と同様に埋め込みやチャンキングの設定も自動的に管理されるため、埋め込みパイプラインを構築する必要はありません。

ドキュメントを投入する

テキストをインデックスすると、埋め込みが自動的に生成されます。

セマンティック検索クエリを実行する

先ほど作成したセマンティックフィールドをクエリします。

そして、結果が返されます。

セマンティック検索は始まりにすぎません。完全なテキストクエリを実行することも、両方を組み合わせてハイブリッドクエリにすることもできます。独自のベクトルクエリを作成して、完全に制御することもできます。詳しい手順については、ドキュメントのセマンティック検索クイックスタートをご覧ください。

Elasticsearchにおけるベクトル検索の今後

私たちは既に次の改善に取り組んでいます。

• より優れたマルチテナント処理：テナントごとにデータを分離する必要がある場合、より少ないコードでより迅速に実現する方法を提供します。

• インデックスの自動最適化：できるだけ手をかけずに、「新規作成直後のインデックス」から「完全に最適化済み」へ。

• 継続的なインフラストラクチャーの改善：Vector Databaseの設定とインフラストラクチャーを継続的に調整することで、常に最高のスループットと最速の対応を得られるようにします。

Elastic Cloud ServerlessでElasticsearchベクトルデータベースをお試しください

本番環境レベルのデフォルト設定がチューニングを行うため、空のプロジェクトから数分でフィルター適用済みのハイブリッドベクトルクエリを作成できます。インフラの構築ではなく、高速でスケーラブルなAIアプリの構築に専念しましょう。

Elastic Cloud Serverlessを開始するか、詳細ドキュメントとAPIリファレンスをご覧ください。

Elastic Cloud Serverlessはインフラストラクチャの管理とバージョンアップグレードの煩わしさをすでに解消していますが、CPSはそれをさらに一歩進めます。複雑なネットワークピアリングと手動による証明書管理を、シンプルなリンクモデルに置き換え、Elastic Cloud Serverlessプロジェクトをデータの単純な名前空間として扱うことができます。厳格なデータレジデンシー法への対応、テナントデータの分離、あるいはログの重複によって発生する莫大なネットワーク送信料金の回避など、どのような場合でも、CPSを使えば、単一のクエリでデータが存在する場所で正確に検索できます。

この投稿では、CPSの仕組み、プロジェクトタグを使用して検索を制御する方法、そしてこの新しいモデルが従来のクラスター横断検索（CCS）とどのように異なるかを説明します。

プロジェクトをリンクしてプロジェクト横断検索を行う方法

プロジェクト横断検索を始めるには、Elastic CloudコンソールまたはAPIでプロジェクトをリンクします。リンクは簡単で一方向です。元となるプロジェクトを選択し、検索するプロジェクトを接続します。これらのリンクはリージョン、クラウドプロバイダー、プロジェクトの種類にまたがるため、統一された検索エクスペリエンスを損なうことなく、データを元の場所に保存できます。

リンクが作成されると、通常約1分以内に有効になります。すでにKibanaを開いている場合は、更新して新しいプロジェクト横断検索機能を確認してください。

プロジェクト横断検索がデフォルトでリンクされたすべてのプロジェクトにクエリを適用する方法

プロジェクトがリンクされると、プロジェクト横断検索は別々のプロジェクトを1つの論理的な検索画面に変えます。ログが複数のプロジェクトにまたがっている場合、FROM logs* のようなクエリは、元のプロジェクトと一致するデータを持つリンクされたプロジェクトを検索します。事前に各リモートターゲットに名前を付ける必要はありません。

これはクラスター横断探索に比べて大きな進歩です。CCSでは、ローカルデータとリモートデータの両方にアクセスするには、 FROM logs*,*:logs*のような記述が必要になることがよくあります。ユーザーにとっては、クエリの複雑さが軽減されるということです。チームにとって、これは分散データ全体にわたる真の可視化の実現に近づくことを意味します。

詳細については、CPS検索モデルドキュメントをご覧ください。

この技術的な詳細については「Elasticsearch Serverlessにおけるプロジェクト横断検索（CPS）の仕組み」をご覧ください。

プロジェクトルーティングによる検索の制御

デフォルトでリンクされたすべてのプロジェクトを検索する機能は、多くのワークフローにとって便利で役立ちますが、すべての検索がすべてのプロジェクトを対象とするべきではありません。プロジェクト横断検索では、プロジェクトルーティングが導入され、クエリを特定のプロジェクト群に限定することが可能になります。

Elastic Cloudで定義されたプロジェクトタグを通じて動作します。すべてのプロジェクトには、そのエイリアス、クラウドプロバイダー、リージョンなどの組み込まれた属性があります。また、 environment:prod, environment:test 、事業部門、顧客名など、組織が資産をどのように考えているかを反映するために、独自のタグを追加することもできます。Elasticsearchはその後、そのメタデータを使用して、どのリンクされたプロジェクトが検索に参加すべきかを決定できます。

プロジェクト横断検索をサポートするすべてのElasticsearchエンドポイントは、project_routing パラメーターを受け付けます。テクニカルプレビューでは、ルーティングはプロジェクトエイリアスの使用に限定されています。例えば、project_routingを _alias:my-linked-project に設定すると、リンクされたプロジェクトにのみクエリが送信され、_alias:_origin は元のプロジェクトにクエリが保持されます。時間の経過とともに、このモデルはより高度なルーティングへの道を開き、検索範囲をインフラの物理的なレイアウトではなく、組織の論理的な構造に従わせることができるようになります。

プロジェクトルーティングに関するドキュメントには、例や仕組みの詳細が記載されていますので、そちらを参照してください。

Kibanaスペースレベルのデフォルトプロジェクトルーティング

検索ルーティングの精度を高める必要がある例として、リンクされたすべてのプロジェクトを検索すると、Kibanaルールで誤検知が殺到したり、既存のダッシュボードで混乱する結果になったりする可能性があります。これを解決するには、Kibanaでスペースレベルのデフォルトプロジェクトスコープを設定することができます。これは、その特定のスペースに対する安全設定として機能します。つまり、すべてのダッシュボード、Discoverセッション、アラートルールは、自動的にこの設定を尊重します。アナリストは、より広範なビューが必要な場合、調査中にスコープを手動で上書きすることができます。

これは、MSP、MSSP、センター・オブ・エクセレンスなど、中心的なプロジェクトを共有するチームにとって重要です。各チームに独自の Kibana スペースを割り当て、特定の顧客プロジェクトのクエリのみに制限することで、テナント固有のエクスペリエンスを保証できます。アナリストは、より広範なビューが必要な場合、調査中にスコープを手動で上書きすることができます。

このスペースのデフォルトは、Cloud UIでプロジェクトを実際にリンクする前でも後でも設定できます。しかし、CPSはリンクが作成された瞬間に「すべて検索」動作を即座に有効にするため、Kibanaのデフォルト設定を先に行うことで、既存の検出ルールが突然膨大なグローバルデータセットに対して実行され、チームに過負荷がかかることを防ぐことができます。

検索でのタグの使用

プロジェクトのルーティングにタグを使用するだけでなく、ES|QLと_searchのクエリでもタグを使用できます。これは、結果セット内の各レコードまたは行がどこから来たのかを特定したり、これらのタグに基づいて並べ替え、フィルタリング、集計したりするのに役立ちます。

例えば、ES|QLレスポンスの各行がどのプロジェクトから来たのかを確認したい場合は、ES|QLクエリに_project._aliasタグを追加できます。

これにより、_project._alias を KEEP 句を含むクエリの他の部分で使用して、最終結果に表示させることができます。

タグをクエリで使用するその他の例については、このドキュメントを参照してください。これには、Search APIとES|QLの両方での使用方法が説明されています。

SearchクエリとES|QLクエリにタグを追加する方法の技術的な詳細については、「プロジェクトタグとルーティングを使用したElasticsearch Serverlessでの高速なプロジェクト横断検索」を参照してください。

プロジェクト横断検索が元のプロジェクトとリンクされたプロジェクトを同等に扱う方法

CCSを使用したことがある方なら、ローカルクラスターはリモートクラスターとはいくつかの点で異なる扱いを受けることをご存知かもしれません。

• ローカルクラスターからのエラーは、リモートクラスターからのエラーとは異なる処理方法があります。特に、CCSはskip_unavailable設定を使用してリモートクラスターからのエラーの動作を制御しますが、その設定はローカルクラスターには存在しません。

• ローカルクラスターには「クラスターエイリアス」がないため、インデックス式 *:logs* はすべてのリモートプロジェクトを検索しますが、ローカルクラスターはスキップされます。両方を検索するには、インデックス式 logs*,*:logs* を使用します。

CPSでは、元のプロジェクトとリンクされたプロジェクトをより均一な基盤に置くために、これらの動作の両方を変更しました。

まず、skip_unavailable設定はElastic Cloud Serverlessでは使われていません。代わりに、_search または _async_search のallow_partial_search_resultsパラメーターまたは ES|QL のallow_partial_resultsパラメーターを使用して、検索で部分的な結果を表示するかどうかを制御します。

次に、Elastic Cloud Serverlessでは、元のプロジェクトにプロジェクトエイリアスがあります。すべてのプロジェクトタグと同様に、Elastic Cloudで定義されています。したがって、CPSでは、以下のすべてのクエリは同等です。それらは「logs」インデックスを持つすべてのプロジェクトを対象としています。

注：修飾インデックス式*:logsと非修飾式logsでは、インデックスが欠落した場合のエラー処理の仕組みに重要な違いがあります。詳細については、公開ドキュメントの「非修飾検索式と修飾検索式」を参照してください。

プロジェクト横断検索のアクセス制御とセキュリティモデル

Elasticは、クラウドベースの新しいセキュリティモデル、ユニバーサルIDおよびアクセス管理（UIAM）を作成しました。これにより、プロジェクト横断検索の重要な原則である「アクセスできるプロジェクトとデータはアクセス元の場所に依存しない」ことが実現されます。

主要なオブザーバビリティプロジェクトから検索を開始する場合でも、アドホックな分析プロジェクトから検索を開始する場合でも、アクセス権限は一元的に定義されているため、リンクされたデータへのアクセスは一貫しています。クラウドベースの認証と承認モデルは、クラウドUIAMサービスを使用して、元のプロジェクトに関係なく、アクセス許可が統一されることを保証します。

プロジェクト横断検索を試す

最終的に、Elastic Cloud ServerlessとCPSを組み合わせることで、運用上の摩擦を軽減し、物理的または運用上の考慮事項ではなく、論理的な考慮事項に基づいてデータを整理するための追加の選択肢が得られます。プロジェクト横断型検索により、ユーザーはデータの論理的な整理にのみ集中でき、従来のような物理的な複雑さを伴わずに統一された検索エクスペリエンスを実現できます。

今日では、こうした局面でもずっとシンプルになります。Elastic Cloud APIキーが、Elastic Cloud Serverless上でElasticsearchとKibana APIに対する直接認証に使用できるようになりました。単一の認証情報を使用して、組織のリソースを管理したり、 Elasticsearchクエリ言語（ES|QL）クエリ、データ取り込み、アラートなどのデータ操作を実行したりできるようになりました。

当社がこれを構築した理由、グローバルに分散されたIDレイヤーをどのように設計して実現した方法、そしてこれがクロスプロジェクト検索の基盤をどのように築くのかを見ていきましょう。

シークレット管理の負担

信頼性の高いCI/CDパイプライン、GitOpsワークフロー、またはTerraformの自動化をデータプラットフォームに構築する際には、隠れたコストが伴います。それは、シークレットの無秩序な拡散です。

以前のモデルでは、開発者は断片的な認証プロセスに直面していました。

• コントロールプレーン（Elastic Cloud APIキー）： Elastic Cloud API経由でプロジェクトの作成、ユーザーの招待、課金管理などを行う際に使用する組織スコープのキー。

• データプレーン（Elasticsearch APIキー）：特定のサーバーレスプロジェクト内で作成され、ElasticsearchおよびKibana APIとやり取りするために使用されるプロジェクトスコープのキー。

つまり、導入スクリプトがElastic Cloudに対して認証を行い、Serverlessプロジェクトをプロビジョニングし、その特定のプロジェクトから新しく作成されたElasticsearch APIキーを抽出し、その後、その2番目のキーを下流のアプリケーションまたは自動化ツールに注入する必要があったことになります。結果として複雑なパイプライン、断片化された監査ログ、認証情報漏洩のリスクの増加につながっていました。

Elastic Cloud Serverlessでの統合認証

このリリースにより、サーバーレスプロジェクトの分割はなくなりました。クラウド、Elasticsearch、Kibana APIsに対して明示的に認可されたElastic Cloud APIキーを作成できるようになりました。

• 以前：Elastic Cloud APIキーは、厳密にはコントロールプレーントークンでした。プロジェクトの作成、請求管理、ユーザー招待は可能だったが、プロジェクト内でElasticsearchやKibanaのAPIを呼び出せないという明確な制限がありました。データ操作には、常にプロジェクト固有の2つ目のキーが必要でした。

• 現在：Elastic Cloud APIキーを作成する際にCloud、Elasticsearch、Kibana APIへのアクセスを選択することで、Serverlessの境界が解除され、そのAPIキーが真に統一された認証情報となります。組織のインフラを管理する能力を維持しながら、同時に任意の認可されたサーバーレスプロジェクトでデータをクエリ、取り込み、分析するためのネイティブアクセスを獲得できます。

これを単一のElastic Cloud APIキーに統合することで、スコープ、監査、ローテーション、取り消しを1つのユニットとして行うことができる単一のIDが得られます。新しいプロジェクトのプロビジョニングであれ、ES|QLクエリの実行であれ、すべてのAPI呼び出しは監査ログに同じ認証情報で記録されるため、インシデント調査やコンプライアンスレビューの際に追跡できる単一の履歴が提供されます。認証情報のローテーションは、分離されたコントロールプレーンとデータプレーンのシークレット間での調整された更新ではなく、ワンステップの操作になります。また、役割の割り当てはプロジェクトごとに行われるため、1つのキーで複数のプロジェクトを横断的に管理でき、監視プロジェクトでのデータ取り込みを管理したり、セキュリティプロジェクトでクエリを実行したりすることが可能になり、プロジェクトごとに個別の認証情報を管理する手間が省けます。

重要なのは、統一されているということは決して全能であることを意味しない点です。role_assignments ペイロードを使用することで、統一されたキーを厳密に単一のプロジェクトと特定のロール（例: 読み取り専用）にスコープすることができ、認証情報が漏洩した場合でも、影響範囲を完全に制限することができます。開発者が退職した場合やアプリケーションが廃止された場合も、Elastic Cloudコンソールから単一のキーを取り消すことで、コントロールプレーンと関連するすべてのElasticsearchプロジェクトへのアクセスを即座に停止できます。

（注：Elastic Cloud Hosted/マネージド導入では、Cloud APIキーは依然としてコントロールプレーンのみを管理します。ホスト型スタックAPIへの対応は今後のリリースで予定されています。）

ワークフローの自動化

始めるのは簡単です。Elastic Cloudコンソールから完全に設定するか、Elastic Cloud APIを使って自動化できます。

UIの操作手順は変わりませんが、プロジェクトロールの割り当て時にCloud、Elasticsearch、Kibana APIへのアクセスを選択できるようになりました。

Elastic Cloud APIを使用してプログラムで統合キーを作成する方法を以下に示します。application_roles配列に注目してください。これが、Elasticsearch データプレーンへのキーのネイティブアクセスを許可します。

一度作成すると、このまったく同じキーをAuthorization: ApiKeyヘッダーでapi.elastic-cloud.comと特定のサーバーレスElasticsearchエンドポイントの両方に渡すだけです。

内部構造：分散型IDレイヤーの構築

Cloud APIキーをコントロールプレーンとデータプレーンの両方で使えるようにするのは、トークンを渡すほど単純ではありません。分散システムの根本的な課題を解決する必要があります。

歴史的に、Cloud APIキーは中央集権的なグローバルセキュリティクラスターに存在していました。これは、より高いレイテンシが許容されるコントロールプレーン操作には問題なく機能しますが、Elasticsearchのデータリクエストには超低レイテンシが求められます。すべての検索クエリやデータ取り込みリクエストを検証するために、地球を横断して中央コントロールプレーンまで往復する余裕はありません。

この問題を解決するため、グローバルに分散されたデータストアを基盤とする新しい認証アーキテクチャを導入しました。次のシーケンス図は、Elastic Cloud APIキーを使用してクライアントがElasticsearchクエリを送信する流れを示しています。グローバルコントロールプレーンへの往復なしに、認証がローカルリージョン内で完結することを示しています。Elasticsearchは認証を地域IAMサービスに委任します。このサービスはキーを検証し、グローバルに分散されたデータベースのローカルレプリカに照らしてロール割り当てを解決します。認可されると、Elasticsearchはクエリを実行し、結果をクライアントに返します。

グローバルに分散された永続性

Elastic Cloud APIキーとそれに関連付けられたロール定義は、中央集権型のセキュリティクラスターにのみ依存するのではなく、グローバルに分散された高可用性データベースに永続的に保存されるようになりました。このデータベースは、サーバーレスプロジェクトが実際に実行されるグローバルコントロールプレーンとリージョナルデータプレーン間で、アイデンティティおよびアクセス管理（IAM）データを同期します。

地域IAMによるローカル検証

クライアントがElastic Cloud APIキーを使用してElasticsearchにリクエストを送信した場合、そのリクエストはグローバルコントロールプレーンには返されません。代わりに、新しい地域IAMサービスにルーティングされます。ローカルデータベースのレプリカに対してキーを検証することで、認証がほぼゼロ遅延で行われ、グローバルなコントロールプレーンの障害から完全に隔離されることを保証します。

動的ロールマッピング

認証は戦いの半分に過ぎず、システムはリクエストを承認する必要もあります。地域IAMサービスは、クラウドレベルのロール割り当て（例：application_roles）をネイティブのElasticsearch権限に即座に変換します。Elasticsearch は、ローカルで.securityインデックスを必要とすることなく、ローカルでリクエストを承認し、実行することができます。

プロジェクト横断検索の基礎

この分散型IDアーキテクチャは、Elastic Platformの将来を支える基本的な構成要素です。

IDとアクセス権限が統一され、グローバルに同期されたことで、異なるプロジェクト間で安全に身元情報をやり取りするために必要なフレームワークが整いました。これにより、Serverless向けのプロジェクト横断検索（CPS）機能が有効になります。

CPSを使用すると、セキュリティとオブザーバビリティのワークロードを組み合わせるなど、複数のリモートServerlessプロジェクトにまたがるデータを、あたかも1つのデータセットであるかのように簡単にクエリできるようになります。統一されたAPIキーを利用することで、システムはすべてのプロジェクトにわたるユーザーの権限を同時に自動的に評価できます。対象プロジェクトごとに複雑な信頼関係、証明書、重複した認証情報を設定する必要はありません。

詳しくはこちら

スタックを簡素化する準備はできていますか？

• スタックアクセスの割り当て方法についてはElastic Cloud APIキーのドキュメントをお読みください。

• キー生成を自動化するには、「APIキーを作成する（Elastic Cloud API）」のリファレンスを参照してください。

• Elasticプラットフォーム全体で使用されているキーの種類を包括的に比較するには、 Elastic APIキーに関するドキュメントを参照してください。

Elastic Cloudでの構築を今すぐ開始または継続しましょう。

免責事項

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

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

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

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

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

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

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

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

• すべてのピザが同じように人気なわけではない。需要が高いものもあれば、需要が少ないものもあります。人気のないものの「コピー」を余分に用意する必要はありません。行列ができているタイプのものを余分に用意する必要があります。

• 行列が長くなる前にピザを追加注文する。友人が完全に手に負えなくなり、ゲストが怒って帰ってしまうまで待つようでは、待ちすぎです。人だかりができているのを見たら、ピザを追加で注文するほうがよいでしょう。

• ピザをすぐに捨ててはいけない。ペパロニピザの人だかりが5分ほどまばらになったからといって、混雑が終わったわけではありません。飲み物を補充しているだけかもしれませんし、あるいは単におしゃべりしているだけかもしれません（今でもそういうことがあるかは別にして）。予備のピザを用意しておいてください。しばらく静かな状態が続くようなら、よけておいても構いません。

• 手伝ってくれる友達の数だけピザを配れる。手伝ってくれる友達が4人しかいない場合は、ピザを10枚配っても結果は変わりません。一度に提供できるピザは4枚だけです。ピザの枚数と手伝いの人数を合わせてください。

• 友達が持ち場を離れるときは、その友達のピザの担当を代わる。友達の誰かが外出する必要があったら、すぐにその友達のピザを引き継ぎます。ピザを放置しておくことはできません。誰かに渡すか、しまっておきます。

ピザからレプリカへ

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

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

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

空腹感の測定

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

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

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

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

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

定義：

• L = インデックスの相対的な検索負荷（0～1の間）。

• N = プロジェクト内で必要な検索ノードの数。

• S = インデックス内のシャード数。

• X = ホットスポットを回避するためのしきい値（デフォルト値：0.5）。

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

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

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

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

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

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

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

トポロジー境界を尊重

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

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

サーバーレスの全体像

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

• 検索自動スケーリングは検索ノードの数を調整します（協力する友人の数）。

• 検索負荷分散のためのレプリカは、インデックスごとのレプリカ数を調整することでトラフィックを分散します（各種のピザが何枚必要かを示すようなものです）。

• データストリームの自動シャード化は書き込みのシャード数を最適化します（各ピザをどのようにカットするかについては前回の投稿をご覧ください）。

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

防御側への示唆

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

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

まとめ

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

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

エージェントは、効率性の向上と顧客体験の向上をもたらす可能性で注目を集めています。しかし実際には、乱雑で構造化されていないエンタープライズデータを扱う場合など、エージェントに適切なコンテキストを提供することは困難です。開発者は、ツール、プロンプト、状態、推論ロジック、モデルを管理し、ビジネスソースから関連するコンテキストを取得して正確な結果とアクションを提供する必要があります。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、セルフマネージドのエンタープライズティアでご利用いただけます。

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

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回実行されました。

• 目標：私たちの目的は、インフラストラクチャーが、急速な自動スケーリングの期間中でも、一貫してより速く、より予測可能なパフォーマンスを提供する能力を検証することでした。

パフォーマンスデータの概要

結果では、効率と速度が大幅に向上したことが確認されました。これらの利点は、ユーザーの応答時間の短縮や、より少ないコンピュートリソースで同じ量の作業を完了できることによる運用コストの削減に直結します。

以下の表は、定量的な改善点の詳細です。スループット値は高いほど好ましく、レイテンシは値が低いほど好ましいです。

検索ベンチマーク結果：

ベンチマーク

比較

旧インフラ

新しいインフラ

差

`wikipedia`（プレーンテキスト）

検索操作のスループット（ops/s）

729

1107

＋52％

`wikipedia`（プレーンテキスト）

検索操作のレイテンシ（p99、ミリ秒）

56

35

-37%

`MSMARCO-Passage-Ranking`（低密度ベクトル）

検索操作のスループット（ops/s）

22

31

+40％

`MSMARCO-Passage-Ranking`（低密度ベクトル）

検索操作のレイテンシ（p99、ミリ秒）

108

67

-38%

`OpenAI_Vector`（高密度ベクトル）

検索操作のスループット（ops/s）

475

624

+31%

`OpenAI_Vector`（高密度ベクトル）

検索操作のレイテンシ（p99、ミリ秒）

35

22

-37%

インデキシングベンチマークの結果：

ベンチマーク

比較

旧インフラ

新しいインフラ

差

`wikipedia`（プレーンテキスト）

検索操作のスループット（ops/s）

2845

3220

+13%

`wikipedia`（プレーンテキスト）

検索操作のレイテンシ（p99、ミリ秒）

1769

1120

-37%

`MSMARCO-Passage-Ranking`（低密度ベクトル）

検索操作のスループット（ops/s）

7087

8900

+26%

`MSMARCO-Passage-Ranking`（低密度ベクトル）

検索操作のレイテンシ（p99、ミリ秒）

824

677

-18%

`OpenAI_Vector`（高密度ベクトル）

検索操作のスループット（ops/s）

2972

3187

+7%

`OpenAI_Vector`（高密度ベクトル）

検索操作のレイテンシ（p99、ミリ秒）

2946

2944

0%

追加のボーナス：コスト削減

私たちは低レイテンシのパフォーマンスを提供することに重点を置いていますが、新しいハードウェアの効率性もElasticsearchプロジェクトのコストに直接的なプラスの影響を与えます。

Elasticsearch Serverlessの価格設定は使用量ベースで、消費した取り込みと検索リソースに対してのみ料金が発生します。新しく高速なハードウェアはより効率的であるため、ワークロードはより少ないリソースを使用してタスクを完了することが多くなり、ほとんどのプロジェクトで本質的なコスト削減につながります。高額な費用をかけずに、最高のパフォーマンス向上を実現できます。まさに効率の最適化です。

開発者にとっての意義

このインフラストラクチャーのアップグレードはElasticによって完全に管理されるため、移行や構成の変更を行う必要はありません。改善は、AWSベースのすべてのサーバーレスプロジェクトで即座かつ自動的に行われます。

このアップグレードにより、次のことが可能になります。

• より高速なアプリケーションを構築：基盤となる検索プラットフォームがユーザーが求める速度を提供していることを認識しながら、機能の速度に重点を置けます。

• 自信を持ってイノベーションを実現：プラットフォームが最高のパフォーマンスで負荷を処理できることを保証しながら、ベクトル検索や関連性ランキングなどの複雑なAI機能を含む新しい検索、オブザーバビリティ、セキュリティの機能をデプロイします。

• スタックを簡素化：インフラ管理、容量計画、スケーリングを処理する完全に管理されたサービスを使用することで、コードとデータに集中できます。

1. リポジトリのクローンを作成します。 git clone https://github.com/elastic/elasticsearch-labs/supporting-blog-content/serverless-ai-agent aを使用して GitHub からツールのコードをダウンロードし、 cd serverless-ai-agentを使用してディレクトリに移動します。

2. 環境の設定: python -m venv venvを使用して仮想環境 (オプション) を作成し、アクティブ化します (Windows の場合はsource venv/bin/activateまたはvenv\Scripts\activate )。次に、 pip install -r requirements.txtを使用して必要な Python パッケージをインストールします。

3. 資格情報を構成する:プロジェクト ルートに.envファイルを作成し、Elasticsearch API URL ( ES_URL )、API キー ( API_KEY )、リージョン ( REGION )、OpenAI API キー ( OPENAI_API_KEY ) を入力します。

4. ツールを実行します:ターミナルでpython main.pyを実行してツールを実行します。これにより、AI エージェントが起動し、コマンドのプロンプトが表示されます。

5. 自然言語でプロジェクトを管理する: 「my\_project という名前のサーバーレス プロジェクトを作成する」、「my\_project という名前のサーバーレス プロジェクトのステータスを取得する」、「my\_project という名前のサーバーレス プロジェクトを削除する」などのわかりやすい英語のコマンドを使用してツールを操作します。AI はコマンドを解釈し、対応する機能を実行します。

背景

この小さなコマンドライン ツールを使用すると、Serverless Elasticsearch プロジェクトをわかりやすい英語で管理できます。AI (この場合は OpenAI) と対話して、ユーザーの意図を理解し、LlamaIndex を使用して適切な関数を呼び出します。

Elasticsearch Serverless AIエージェントは何ができるのか

• プロジェクトを作成する: 新しい Serverless Elasticsearch プロジェクトを起動します。

• プロジェクトの削除: 既存のプロジェクトを削除します (削除後はクリーンアップされます)。

• プロジェクトのステータスを取得: プロジェクトの進行状況を確認します。

• プロジェクトの詳細を取得: プロジェクトに関するすべての重要な詳細を取得します。

GitHub でコードを確認してください。

Elasticsearch Serverless AIエージェントの仕組み

次のように入力すると:

「my_project という名前のサーバーレス プロジェクトを作成する」

…舞台裏ではこんなことが起こっています:

• ユーザー入力とコンテキスト:自然言語コマンドが AI エージェントに送信されます。

• 関数の説明:詳細な説明が与えられているため、AI エージェントは、create_ess_project、delete_ess_project、get_ess_project_status、get_ess_project_details などのいくつかの関数についてすでに認識しています。これらの説明は、各関数が何を実行し、どのようなパラメータが必要かを AI に伝えます。

• LLM 処理:クエリと関数情報が LLM に送信されます。つまり、AI は次のことを認識します。

  • ユーザークエリ: わかりやすい英語での指示。

  • 利用可能な機能と説明: 各ツールの機能の詳細により、適切なツールを選択できます。

  • コンテキスト/履歴チャット情報: 会話なので、以前に話された内容を記憶します。

• 関数の呼び出しと応答: AI はどの関数を呼び出すかを判断し、適切なパラメーター (プロジェクト名など) を渡して、関数が実行されます。応答はわかりやすい形式で返されます。

つまり、自然言語クエリと詳細なツール説明のリストの両方を LLM に送信して、LLM がそれを「理解」し、リクエストに適したアクションを選択できるようにします。

AIエージェントを設定する

前提条件:

AI エージェントを実行する前に、次の設定がされていることを確認してください。

1. Python (v3.7 以降)がインストールされています。

2. Elastic Cloud にセットアップされたElasticsearch サーバーレス アカウント。

3. 言語モデルと対話するためのOpenAI アカウント。

手順:

1. リポジトリをクローンします。

2. 仮想環境を作成する (オプションですが推奨):環境関連の問題に直面している場合は、分離のために仮想環境を設定できます。

3. 依存関係をインストールします。次のコマンドを実行して、必要な依存関係がすべてインストールされていることを確認します。

4. 環境を設定する: .env を作成するプロジェクト ルートに次の変数を含むファイルを作成します。以下に、役に立つサンプルの.env.exampleファイルを示します。

ES_URL 、 API_KEY 、 OPENAI_API_KEYの値が正しいことを確認してください。API キーはそれぞれのサービス ダッシュボードで確認できます。

5. プロジェクト ファイル:ツールは、 projects.jsonファイルを使用してプロジェクト マッピング (プロジェクト名とその詳細) を保存します。このファイルが存在しない場合は自動的に作成されます。

AIエージェントの実行

次のようなプロンプトが表示されます。

コマンドを入力すると、AI エージェントが魔法のように動作します。完了したら、 exitまたはquitと入力して終了します。

さらに詳しい情報

• LLM 統合: LLM には、クエリと利用可能な各機能の詳細な説明の両方が提供されます。これにより、コンテキストを理解し、たとえば、 create_ess_projectを呼び出すかdelete_ess_projectを呼び出すかを決定するのに役立ちます。

• ツールの説明: 各関数ツール (FunctionTool.from_defaults を使用して作成)親切な説明があります。この説明は LLM に送信されるプロンプトに含まれているため、LLM は利用可能なアクションと各アクションで期待される内容を「認識」します。

• 永続性: プロジェクトとその詳細はprojects.jsonに保存されます。毎回情報を再入力する必要がなくなります。

• 詳細ログ: エージェントは詳細モードに設定されており、デバッグや、命令が関数呼び出しにどのように変換されるかを確認するのに最適です。

Elasticsearch AIエージェントの利用例

出発点

Elasticsearchの最初のバージョンは、ユーザーが重要な洞察をすばやく検索して明らかにすることを可能にする、分散型のスケーラブルな検索エンジンとして 2010 年にリリースされました。12 年が経過し、65,000 件を超えるコミットが行われた現在でも、Elasticsearch はさまざまな検索問題に対する実証済みのソリューションをユーザーに提供し続けています。数百人の Elastic フルタイム従業員を含む 1,500 人を超える貢献者の努力のおかげで、Elasticsearch は検索分野で発生する新しい課題に対応できるよう絶えず進化してきました。

Elasticsearch のリリース初期にデータ損失の懸念が浮上したとき、Elastic チームは、確認されたデータが安全に保存されることを保証するために、クラスター調整システムを書き換える作業を数年にわたって行いました。大規模なクラスター内のインデックスの管理が面倒であることが明らかになったため、チームは、ユーザーがインデックス パターンとライフサイクル アクションを事前に定義できるようにすることでこの作業を自動化する広範なILM ソリューションの実装に取り組みました。ユーザーが大量のメトリックおよび時系列データを保存する必要性に気付いたため、データ サイズを削減するために、より優れた圧縮などのさまざまな機能が追加されました。大量のコールド データを検索するためのストレージ コストが増大したため、低コストのオブジェクト ストアでユーザー データを直接検索する方法として、検索可能なスナップショットの作成に投資しました。

これらの投資は、Elasticsearch の次の進化の基盤を築きます。クラウド ネイティブ サービスと新しいオーケストレーション システムの成長に伴い、クラウド ネイティブ システムを操作する際のエクスペリエンスを向上させるために Elasticsearch を進化させる時期が来たと判断しました。これらの変更により、 Elastic Cloudで Elasticsearch を実行する際の運用、パフォーマンス、コストの改善につながると考えています。

目指すところ - ステートレスアーキテクチャの採用

Elasticsearch を操作またはオーケストレーションする際の主な課題の 1 つは、Elasticsearch が多数の永続的な状態に依存しているため、ステートフル システムであることです。3 つの主要な部分は、トランスログ、インデックス ストア、およびクラスター メタデータです。この状態は、ストレージが永続的である必要があり、ノードの再起動または置き換え中に失われないことを意味しています。

Elastic Cloud 上の既存の Elasticsearch アーキテクチャでは、停止の場合に冗長性を確保するために、複数のアベイラビリティゾーンにわたってインデックスを複製する必要があります。私たちはこのデータの永続性をローカル ディスクから AWS S3 などのオブジェクト ストアに移行するつもりです。このデータの保存に外部サービスを利用することで、インデックスのレプリケーションの必要性がなくなり、取り込みに関連するハードウェアが大幅に削減されます。このアーキテクチャでは、AWS S3、GCP Cloud Storage、Azure Blob Storage などのクラウド オブジェクト ストアが可用性ゾーン間でデータを複製する方法により、非常に高い耐久性の保証も提供されます。

インデックス ストレージを外部サービスにオフロードすると、インデックス作成と検索の役割を分離して Elasticsearch を再設計することも可能になります。プライマリインスタンスとレプリカインスタンスで両方のワークロードを処理するのではなく、インデックス層と検索層を用意する予定です。これらのワークロードを分離することで、ワークロードを個別にスケーリングできるようになり、それぞれのユースケースに的を絞ったハードウェア選択が可能になります。また、検索とインデックス作成の負荷が相互に影響を与える可能性があるという長年の課題の解決にも役立ちます。

数か月にわたる概念実証と実験段階を経て、これらのオブジェクト ストア サービスは、インデックス ストレージとクラスター メタデータに対して想定されている要件を満たしていると確信しています。当社のテストとベンチマークでは、これらのストレージ サービスは Elastic Cloud で確認された最大規模のクラスターの高いインデックス作成ニーズを満たすことができることが示されています。さらに、データをオブジェクト ストアにバックアップすることで、インデックス作成のコストが削減され、検索のパフォーマンスを簡単に調整できるようになります。データを検索するために、Elasticsearch は、データがクラウドネイティブのオブジェクト ストアに永続的に保存され、頻繁にアクセスされるデータのキャッシュとしてローカル ディスクが使用される、実績のある検索可能なスナップショット モデルを使用します。

区別を容易にするために、既存のモデルを「ノード間」レプリケーションと呼びます。このモデルのホット層では、プライマリ シャードとレプリカ シャードの両方が、取り込みを処理し、検索リクエストに対応するために同じ重い作業を実行します。これらのノードは、ホストするシャードのデータを安全に永続化するためにローカル ディスクに依存するという点で「ステートフル」です。さらに、プライマリ シャードとレプリカ シャードは同期を維持するために常に通信しています。これは、プライマリ シャードで実行された操作をレプリカ シャードに複製することによって行われます。つまり、指定されたレプリカごとにそれらの操作のコスト (主に CPU) が発生します。取り込みのためにこの作業を実行する同じシャードとノードが検索リクエストも処理するため、プロビジョニングとスケーリングは両方のワークロードを考慮して実行する必要があります。

検索と取り込み以外にも、ノード間レプリケーション モデルのシャードは、Lucene セグメントのマージなど、他の集中的な責任も処理します。この設計にはメリットもありますが、長年にわたりお客様から学んだことや、より広範なクラウド エコシステムの進化に基づいて、多くのチャンスがあることに気づきました。

新しいアーキテクチャにより、次のような多くの即時および将来の改善が可能になります。

1. 同じハードウェア上で取り込みスループットを大幅に向上させることができます。言い換えれば、同じ取り込みワークロードの効率を大幅に向上させることができます。この増加は、レプリカごとにインデックス操作の重複が削除されたことで発生します。CPU を集中的に使用するインデックス作成操作は、インデックス作成層で 1 回だけ実行すればよく、その後、結果のセグメントがオブジェクト ストアに送信されます。そこから、データは検索層でそのまま使用できるようになります。

2. コンピューティングとストレージを分離して、クラスター トポロジを簡素化できます。現在、Elasticsearch には、データをハードウェア プロファイルと一致させるための複数のデータ層 (コンテンツ、ホット、ウォーム、コールド、フローズン) があります。ホット層はほぼリアルタイムの検索用であり、フローズン層は検索頻度の低いデータ用です。これらの層は価値を提供しますが、複雑さも増大します。新しいアーキテクチャでは、データ層が不要になり、Elasticsearch の構成と操作が簡素化されます。また、インデックス作成と検索を分離することで複雑さがさらに軽減され、両方のワークロードを個別に拡張できるようになります。

3. ローカル ディスクに保存する必要があるデータの量を減らすことで、インデックス層のストレージ コストを削減できます。現在、Elasticsearch はインデックス作成のために、ホット ノード (プライマリとレプリカの両方) に完全なシャード コピーを保存する必要があります。オブジェクト ストアに直接インデックスを作成するステートレス アプローチでは、ローカル データの一部のみが必要になります。追加のみのユースケースでは、インデックス作成のために特定のメタデータのみを保存する必要があります。これにより、インデックス作成に必要なローカル ストレージが大幅に削減されます。

4. 検索クエリに関連するストレージ コストを削減できます。検索可能なスナップショット モデルをデータ検索のネイティブ モードにすることで、検索クエリに関連するストレージ コストが大幅に削減されます。ユーザーの検索待ち時間のニーズに応じて、Elasticsearch では頻繁に要求されるデータのローカル キャッシュを増やす調整が可能になります。

ベンチマーク - インデックス作成スループットが75%向上

このアプローチを検証するために、データが単一のノードでのみインデックス化され、レプリケーションがクラウド オブジェクト ストアを通じて実現される、広範な概念実証を実装しました。インデックスのレプリケーションに専用のハードウェアを用意する必要がなくなることで、インデックスのスループットが 75%向上することがわかりました。さらに、オブジェクト ストアからデータを取得するだけの CPU コストは、今日のホット層に必要な、データのインデックス作成とローカルへの書き込みよりもはるかに低くなります。つまり、検索ノードは CPU を完全に検索専用にできるようになります。

これらのパフォーマンス テストは、3 つの主要なパブリック クラウド プロバイダー (AWS、GCP、Azure) すべてに対して 2 ノード クラスターで実行されました。私たちは、実稼働ステートレス実装を追求しながら、より大きなベンチマークを構築し続けるつもりです。

インデックス作成スループット

CPU使用率

私たちにとって無国籍、あなたにとって貯蓄

Elastic Cloud のステートレス アーキテクチャにより、インデックス作成のオーバーヘッドを削減し、取り込みと検索を個別に拡張し、データ層の管理を簡素化し、スケーリングやアップグレードなどの操作を高速化できます。これは、Elastic Cloud プラットフォームの大幅な近代化に向けた最初のマイルストーンです。

Elasticsearchのステートレスビジョンに参加しませんか

誰よりも先にこのソリューションを試してみませんか?ディスカッションまたはコミュニティ Slack チャンネルで私たちに連絡を取ることができます。新しいアーキテクチャの方向性を決めるために、皆様からのフィードバックをお待ちしています。