Claude Media
Elasticsearch MCPサーバーの使い方 — 非推奨化とAgent Builder移行
Claude CodeMCPClaude連携チュートリアル

Elasticsearch MCPサーバーの使い方 — 非推奨化とAgent Builder移行

Elastic公式のElasticsearch MCPサーバーは非推奨化され、後継のAgent Builder MCPエンドポイントへの移行が進んでいます。両方の接続手順と違いをまとめます。

読了目安 約12分

Elasticsearch向けの公式MCPサーバーelastic/mcp-server-elasticsearchは、READMEの冒頭に非推奨(deprecated)の警告が入っています。今後は重大なセキュリティ更新のみが提供され、後継として案内されているのはElastic Agent Builderが提供するMCPエンドポイントです。すでに動いている接続を持つチームは既存の手順を知っておく必要があり、これから新規に繋ぐチームは最初からAgent Builder側を選んだほうが手戻りが少なくなります。両方の接続方法と、何が変わったのかをまとめます。

Elasticsearch MCPサーバーで何ができるか

MCPはAIエージェントと外部ツールをつなぐ標準プロトコルです。仕組み自体はMCPとはにまとめています。ElasticsearchのMCPサーバーが提供する役割は明快で、インデックスに対する自然言語での検索・分析です。SQLでもDSLでもなく、日本語や英語の質問文のままElasticsearchのデータに触れます。

現行サーバーが公開しているツールは5つです。

ツール名機能
list_indices機能利用可能なインデックスを一覧表示
get_mappings機能指定インデックスのフィールドマッピングを取得
search機能Query DSLによる検索を実行
esql機能ES|QLクエリを実行
get_shards機能全体または指定インデックスのシャード情報を取得

スキーマをget_mappingsで把握してからsearchやesqlで問い合わせる、という流れがそのままAIエージェントの思考過程に載る形です。運用状態を見たいときはget_shardsでシャードの分布を確認できます。

現行サーバーの接続手順(Docker)

現行のmcp-server-elasticsearchはDockerコンテナイメージとして配布されており、docker.elastic.co/mcp/elasticsearchから取得します。プロトコルはstdioとstreamable-HTTPの2つから選べます(SSEは非推奨)。

接続前に、ElasticsearchクラスターのURLと認証情報を用意します。認証はAPIキーかユーザー名・パスワードのどちらかです。

docker run -i --rm \
  -e ES_URL \
  -e ES_API_KEY \
  docker.elastic.co/mcp/elasticsearch \
  stdio

Claude Desktopに登録する設定はJSON形式で、環境変数をenvブロックに直接書き込みます。

{
  "mcpServers": {
    "elasticsearch-mcp-server": {
      "command": "docker",
      "args": [
        "run", "-i", "--rm",
        "-e", "ES_URL",
        "-e", "ES_API_KEY",
        "docker.elastic.co/mcp/elasticsearch",
        "stdio"
      ],
      "env": {
        "ES_URL": "<elasticsearch-cluster-url>",
        "ES_API_KEY": "<elasticsearch-API-key>"
      }
    }
  }
}

Webベースの統合や複数クライアントからの同時接続には、streamable-HTTPモードのほうが向いています。

docker run --rm \
  -e ES_URL \
  -e ES_API_KEY \
  -p 8080:8080 \
  docker.elastic.co/mcp/elasticsearch \
  http

このモードではエンドポイントがhttp://<host>:8080/mcp、ヘルスチェックがhttp://<host>:8080/pingで応答します。stdioしか対応していないクライアント(Claude Desktopの無償版など)からHTTPサーバーに繋ぎたい場合は、mcp-proxyでstdioとstreamable-HTTPの橋渡しをします。

コンテナが正常に動作しているかはdocker psで状態を確認し、接続不良の原因調査にはdocker logsが使えます。

docker ps | grep elasticsearch-mcp-server
curl http://localhost:8080/ping

/pingがpongを返せば、コンテナからElasticsearchクラスターまで正常に疎通しています。

後継のAgent Builder MCPエンドポイントへの移行

Elastic Agent Builderは、Kibana側で管理するツール群を外部のMCPホストに公開する仕組みです。エンドポイントは次の形式で、Kibana Spaceを使っている場合はスペース名をパスに含めます。

{KIBANA_URL}/api/agent_builder/mcp
{KIBANA_URL}/s/{SPACE_NAME}/api/agent_builder/mcp

利用できる範囲はデプロイ形態で分かれます。Serverless版のElasticsearch・Observability・Securityプロジェクトはいずれも一般提供(GA)済みです。Elastic Stackでは9.3でGA、9.2ではプレビュー扱いです。旧サーバーのDocker配布と違い、こちらはKibanaの機能として組み込まれているため追加のコンテナを自前で運用する必要がありません。

認証方式はAPIキーとOAuth 2.1の2択です。

観点APIキーOAuth
対応環境APIキーElastic Stack・Serverless両方OAuthServerlessのみ
向く用途APIキー自動化・共有マシン間連携OAuth個人が使うClaude DesktopやCursorなど
権限APIキーキー発行時点の権限をスナップショットOAuthログインユーザーの現在の権限がそのまま反映
有効期限APIキーキーが失効・削除されるまで長期OAuth短命トークンを自動更新。30日以上未使用で再接続が必要

複数人のチームで同じAgent Builderに繋ぐ場合、APIキーは1つの鍵を全員で共有する形になり、権限もその鍵の時点のものに固定されます。OAuthならクライアント登録は1つで済みつつ、各人が個別に同意して自分の権限で動くコネクションを持てます。Serverlessでプロジェクトを横断検索するcross-project searchを連携済みの場合、ツール呼び出しはMCP URLに紐づくスペースのデフォルトスコープに従います(プレビュー機能)。

現行サーバーとAgent Builderの違い

同じ「ElasticsearchをMCP経由でClaudeから触る」でも、扱える範囲が異なります。

項目現行サーバー(非推奨)Agent Builder MCPエンドポイント
ホスティング現行サーバー(非推奨)自前でDockerコンテナを起動Agent Builder MCPエンドポイントKibanaに組み込み済み
ツール範囲現行サーバー(非推奨)検索・マッピング取得など5ツール固定Agent Builder MCPエンドポイントElastic Workflowsを含む全ツールカタログ
認証現行サーバー(非推奨)APIキーまたはBasic認証Agent Builder MCPエンドポイントAPIキーまたはOAuth 2.1
保守現行サーバー(非推奨)重大なセキュリティ更新のみAgent Builder MCPエンドポイント現行の開発ライン

現行サーバーの5ツールは検索と分析に絞られていますが、Agent BuilderはKibana上で定義したWorkflowsまで含めた全ツールカタログを公開できます。単純な検索だけなら現行サーバーでも動きますが、今から新規に構築するなら移行前提でAgent Builder側を選ぶほうが、将来同じ設定を作り直す手間を避けられます。

セキュリティと運用の注意点

現行サーバーの認証情報はコンテナに渡す環境変数としてのみ保持され、ディスクへの永続化やログ出力はされません。本番でAPIキーを直書きせず、AWS Secrets ManagerやSystems Manager Parameter Storeのようなシークレット管理サービス経由で注入する運用が推奨されています。APIキーには読み取り専用・対象インデックス限定の最小権限を与え、30〜90日ごとのローテーションが基本です。この最小権限の考え方は、後継のAgent Builder側でも同じです。APIキー認証を選ぶ場合、キーの権限がそのままMCP経由での操作範囲になります。

通信経路の暗号化は、ES_URLをhttps://で指定していればMCPサーバーとElasticsearch間もHTTPS化されます。保存データの暗号化はコンテナ側では扱わず、Elasticsearchクラスター自体の暗号化設定に委ねられます。コンテナはデータをローカルに保持しないため、暗号化の責任範囲はクラスター側だけに絞って考えられます。

よくあるつまずき

  • streamable-HTTPで繋いだのに応答がない: MCP-Protocol-Versionヘッダーを送らないクライアントは古いハンドシェイクにルーティングされる。モダンなクライアントは毎回のPOSTリクエストでヘッダーを明示する
  • SSL証明書エラーで接続できない: 開発・検証環境限定でES_SSL_SKIP_VERIFY=trueを使えるが、本番クラスターでは証明書を正しく設定するのが前提
  • v0.3.1からv0.4.0に上げたら設定が通らない: 0.4.0で設定方法が変わっている。移行時はREADMEの該当バージョンの手順に必ず読み替える
  • Agent Builder側でOAuthの接続が切れる: 30日以上未使用のOAuth接続は再認可が必要になる。定期的に使わないコネクションは自動的に失効する仕様として扱う

よくある質問

Docker以外の実行方法はありますか

配布元のドキュメントで案内されているのはコンテナイメージ(docker.elastic.co/mcp/elasticsearch)経由のみです。pipやバイナリでの直接配布は案内されていないため、実行にはDockerまたはPodmanのようなOCI互換ランタイムが前提になります。

Claude Desktop以外のクライアントでも使えますか

使えます。配布元は前提条件としてClaude Desktop・Cursor・VS Code・その他MCP対応クライアントを挙げており、Claude Code固有の手順が明記されていない分はclaude mcp addの一般的な変換手順で対応できます。

現行サーバーはいつまで動きますか

明確な終了日は案内されていません。今後受けられるのは重大なセキュリティ更新のみで、新機能や通常のバグ修正は入らない前提です。長期運用するなら、Elasticsearch側のバージョンがAgent Builderの対象(9.2以降)に達し次第、移行を検討する計画にしておくのが安全です。

まとめ

Elasticsearchの公式MCPサーバーは非推奨に切り替わり、後継はKibanaに組み込まれたAgent Builder MCPエンドポイントです。すでにDockerベースの現行サーバーを運用しているなら、list_indicesやesqlを含む5ツールはそのまま動き続けますが、受けられるのは重大なセキュリティ更新だけです。Elasticsearch 9.2以降やServerlessプロジェクトを使っているなら、Agent Builder側のエンドポイントに切り替えることでElastic Workflowsまで含む広いツールカタログにアクセスできます。個人利用ならOAuth、自動化やチーム共有ならAPIキーという認証方式の使い分けを踏まえたうえで、新規構築はAgent Builder側を起点にするのが手戻りの少ない選択です。分析基盤を横断してMCPからClaudeに繋ぐ発想は、OLAPクエリに寄せたClickHouse MCPサーバーやローカル分析基盤のDuckDB / MotherDuck MCPサーバーにも共通しています。PostgreSQLのように単一プロダクトに特化したMCPサーバーの設計はPostgreSQL MCPサーバーの使い方でも扱っているので、あわせて参考にできます。

この記事を共有:XはてブLinkedIn

関連する記事

Claude Code をもっと見る →