Elasticsearch MCP Serverを試用してみる
makイントロ
流行りの AI 界の USB-C こと（笑）MCPとは何かがわからないので
https://github.com/modelcontextprotocol で参照されていた
https://github.com/elastic/mcp-server-elasticsearch を試しに使ってみて感覚をつかむ
This repository contains experimental features intended for research and evaluation and are not production-ready.
Connect to your Elasticsearch data directly from any MCP Client (like Claude Desktop) using the Model Context Protocol (MCP).
This server connects agents to your Elasticsearch data using the Model Context Protocol. It allows you to interact with your Elasticsearch indices through natural language conversations.
ということで、今回使う対象はMCPサーバなれど規模は小さく、ユーザー視点ではClaude DesctopのUIに入れるプラグイン（クライアント）のように見えそう から図を拝借するとこうらしい
自宅のRaspberrypiに構築した貧弱なElasticSearchを使って楽にClaudeDesktopをつなぐので
今回は図のRemote Service CをESに該当させる
MCPの通信は今回の構成ではClaudeDesktopに内包されてしまうので、意識されない
プロトコル仕様はこのあたりらしい
MCPサーバとESは図にあるようにWeb通信
mak構築
- ClaudeDesktopをインストールする
- 設定を書く
- 自己証明書でエラーが出る
{
"mcpServers": {
"elasticsearch-mcp-server": {
"command": "npx",
"args": [
"-y",
"@elastic/mcp-server-elasticsearch"
],
"env": {
"ES_URL": "https://192.168.1.1:9200",
"ES_API_KEY": "==",
"ES_CA_CERT": "C:\\Users\\escert.pem.txt", # 効いているか不明
"NODE_TLS_REJECT_UNAUTHORIZED": "0"
}
}
}
}
- 書かれていなさそうだがnode.jsも必要な空気なのでインストールする
- ESはローカルネットワークにRaspberrypiで建っている
mak試行①
ClaudeDesktopに自然言語を入力する
コードをいきなり書き始めるが、欲しいのは結果なので慌てて止める
インデックスの取得は具体的な指示なしで完璧
アグリゲーションがうまく動作していない模様 KQLが悪いのか、ESサーバ設定が悪いのかは未検証
諦めて力技で一週間分 for day in daysしに行く模様
最終結果は正解 途中でコード生成を停止して指示を出しなおした以外は自動で二分程度かかっている
レコードはUTC＋０で入っていて、実行環境はUTC＋９だがそのあたりの配慮はなかった。言えばやってくれるとは思う
mak試行②：応用
もう少し高度な分析をさせる
さっきはデバイスの種類を考慮していなかったが、突然考慮し始める 結果はあっている
アグリゲーション集計がさっきと同様失敗するのでまた力技微分のようなことを始める
１分Δtで４８時間分をスキャンしようとしており、機械の発想としてはあっているのかもしれないが、API枯渇し終了 そこまで読めていないという点ではコストコントロールはできていないが、最初に指示すれば大丈夫かもしれない
mak感想
-
明快なクエリ（MaxやMin程度）はバシッと回答してくれるのでよい
- ただし、明快なクエリは熟練者ならKQLを書いた方が速い
- 対象のインデックスが大量かつ未知な場合にはこのようなツールを使うと効果が出るかもしれない
- 大量にキーがある半構造化ログがあったとして(audit.logのような)、やりたいことを入力してシンプルなKQLを生成してもらい、それをまたプロンプトで練ってからクエリを投入する、くらいの使い方はしっくりきた。
-
ある程度複雑な調査や推論は（安いモデルでは）まだやってくれそうにない
- 例えば湿度変化から入浴時間を推定して、というプロンプトはうまく動作しなかったし、指示を都度調整しなくてはならない→時間やAPI Quotaを結構消費する
- とはいえ人がやっても時間はかかるしコストも高いので、どちらが良いかはもう少し調べる価値はある
-
プロンプトの工夫の余地はかなりありそう（すぐに陳腐化しそうでもある）
-
LLMで使えるプロトコル、という方向は間違いなく合っているので今後に期待したい