Elasticsearch は、ログやメトリクスの検索・分析に広く使われている分散型検索エンジンです。これまでの検索には Lucene ベースの DSL が広く使われてきましたが、2023年に登場した新しいクエリ言語「ES|QL（Elasticsearch Query Language）」によって、より柔軟で強力な分析が可能になりました。 目次 概説 ES|QL とは？ ES|QL の主な特徴 ユースケース ES|QL を使うには？ サンプル実行 1. 準備：環境 2. サンプルデータの準備 3. 基本のクエリ 4. 条件で絞り込む 5. 集計してみる 6. 時系列での分析 7. ダッシュボードへのグラフの追加 7.1. Discover からダッシュボードへ追加する方法 7.2. ダッシュボードから直接追加する方法 8. Dev Tools からの実行 まとめ 概説 ES|QL とは？ ES|QL は、Elasticsearch に特化した新しいクエリ言語で、パイプ構文を使って複数の処理を直感的に記述できるのが特徴です。UNIX のパイプ（|）のように、クエリの各ステップをつなげてデータを変換・整形・集計していくスタイルは、ログ分析やセキュリティ監視において非常に有効です。 例： FROM kibana_sample_data_logs | STATS count = COUNT() by clientip | SORT count DESC | LIMIT 10 このように、clientip ごとのアクセス数を集計し、降順に並べる処理をシンプルに記述できます。 ※ES|QLの文法の詳細については、 公式ドキュメント を参照してください。 ES|QL の主な特徴 パイプ構文：複数の処理を直列につなげて記述できる 高速実行：Elasticsearch の分散処理と統合されており、大量データでも高速 直感的な構文：SQL に似た構文で学習コストが低い 一貫した操作：フィルタ・集計・変換が一貫して可能（WHERE、STATS、KEEP など） ユースケース ES|QL は特に以下のようなユースケースで威力を発揮します： セキュリティログの異常検知 アプリケーションログのエラーパターン分析 メトリクスの時系列集計と可視化 Kibana でのダッシュボード作成やアラート設定 ES|QL を使うには？ ES|QL は、Elasticsearch 8.11 以降で正式に利用可能です。Kibana の Discover や Dev Tools から直接クエリを実行できるほか、API 経由でも利用できます。 POST /_query { "query": "FROM kibana_sample_data_logs | STATS count = COUNT() by clientip | SORT count DESC | LIMIT 10" } サンプル実行 ここからは、実際に ES|QL を試してみましょう。 1. 準備：環境 Elasticsearch 8.11 以降 (筆者は、Elasticsearch 9.1.4 で検証) ES|QLを利用可能な場所： Kibana の Discover Kibana の Dev Tools Kibana の Dashboard API 経由 ※Elastic Security の detection rule でも利用可能ですが、本記事では割愛します。詳しく知りたい方は 公式ドキュメント を参照してください。 2. サンプルデータの準備 Kibana には、3種類のサンプルデータが用意されています。今回は、そのうちの kibana_sample_data_logs を利用します。 手順： 2.1. Kibana にログインし、Home 画面を表示します。 2.2. Home 画面から Try sample data をクリックします。 2.3. Sample data タブの > Other sample data sets を展開します。 2.4. Sample web logs の [Add data] をクリックします。 2.5. しばらく待ちます。 2.6. [View data] と表示されれば、サンプルデータの取り込み完了です。 3. 基本のクエリ まずは kibana_sample_data_logs インデックスからデータを取得してみましょう。 3.1. Analytics / Discover 画面に遷移します。 3.2. 画面上部の [Try ES|QL] をクリックします。 ES|QL を入力する画面に切り替わります。 3.3. クエリーの入力欄に次の ES|QL クエリーを入力し、 [▶ Run] を押します。 FROM kibana_sample_data_logs | LIMIT 5 3.4. 最初の5件がリストに表示されます。 表示されない場合は、対象となる期間を調節してみてください。(Last 1 year など) 4. 条件で絞り込む response が “200” でないドキュメントだけを抽出するには WHERE を使います。 FROM kibana_sample_data_logs | WHERE response != "200" | KEEP @timestamp, response, clientip, url | LIMIT 10 KEEP を使うと必要なフィールドだけを残せるため、ログの可読性が向上します。 5. 集計してみる clientip ごとのアクセス数を集計してみましょう。 FROM kibana_sample_data_logs | STATS count = count() BY clientip | SORT count DESC | LIMIT 10 アクセス数の多い clientip を簡単に特定できます。 6. 時系列での分析 時間ごとのアクセス数を確認するには DATE_TRUNC(), STATS, BY を組み合わせます。 FROM kibana_sample_data_logs | EVAL hour = DATE_TRUNC(1h, timestamp) | STATS count = count() BY hour | SORT hour ASC これで「1時間ごとのアクセス数」をグラフ化でき、ピーク時間帯を把握できます。 7. ダッシュボードへのグラフの追加 ES|QL の結果をグラフとしてダッシュボードへ追加するには、2つの方法があります。 7.1. Discover からダッシュボードへ追加する方法 7.1.1. Discover 画面のグラフの右上のフロッピーディスクアイコンをクリックします。 7.1.2. Save Lens visualization ダイアログが開くので、Title, 追加先のダッシュボード名などを入力して、[Save and go to Dashboard] をクリックします。 ※注 （将来的には変わるかもしれませんが）v9.1.4 の時点では、library に追加することはできません。 7.1.3. ダッシュボードへグラフが追加されます。 7.2. ダッシュボードから直接追加する方法 7.2.1. ダッシュボードを新規作成します。あるいは、既存のダッシュボードを開きます。 7.2.2. [ (+) Add panel ] をクリックします。 7.2.3. Visualizations から ES|QL をクリックします。 7.2.4. クエリーの入力欄が表示されるので、そこに実行したい ES|QL のクエリーを入力し、[ ▷ Run query ] をクリックします。 7.2.5. 左側にグラフが表示されるので、それで問題なければ [Apply and close] をクリックします。 7.2.6. ダッシュボードへグラフが追加されます。 8. Dev Tools からの実行 Dev Tools の Console から ES|QL で問い合わせを行うには、 POST /query { "query": "..." } という形式を利用します。 Dev Tools の Console を開いて、下記を実行してみてください。 POST /_query { "query": """ FROM kibana_sample_data_logs | WHERE @timestamp >= NOW() - 10d | STATS count = COUNT() by clientip | SORT count DESC | LIMIT 10 """ } レスポンス { "took": 11, "is_partial": false, "documents_found": 14024, "values_loaded": 0, "columns": [ { "name": "count", "type": "long" }, { "name": "clientip", "type": "ip" } ], "values": [ [ 100, "30.156.16.164" ], [ 29, "164.85.94.243" ], [ 26, "50.184.59.162" ], [ 26, "236.212.255.77" ], [ 25, "16.241.165.21" ], [ 25, "246.106.125.113" ], [ 24, "111.237.144.54" ], [ 24, "81.194.200.150" ], [ 23, "56.28.213.27" ], [ 23, "26.131.108.13" ] ] } POST /query の構文については、 公式ドキュメント を参照してください。 まとめ ES|QL の特徴は以下の通りです。： パイプ構文で直感的に書ける フィルタ・集計・変換を一貫して実行できる ログ分析やセキュリティ監視に最適 まずはシンプルなクエリから試し、徐々に複雑な分析へと広げていくのがおすすめです。Kibana の可視化機能と組み合わせれば、リアルタイムに「気づき」を得られる強力な武器になります。 The post Elasticsearch ES|QL 入門：ログ分析をもっとスマートに first appeared on Elastic Portal .

「AIアシスタントに任せよう」、そんな言葉が日常的に使われる時代がやってきました。 例えば、PerplexityとPayPalが提携し、AIが「探す→比べる→支払う」までをつなぐエージェント型コマースを実装するとされ、個人の買い物体験がチャット完結に近づいています。また、2024年には企業のAI導入率が70%を超え、AIは単なる便利ツールから共に考え働くパートナー、同僚という位置にへと変化しています。 その背景には「LLM」「RAG」「Agentic」「MCP」「A2A」といった進化の階段があります。本記事では、それぞれがどのように繋がり、未来を形作っているのかを整理します。 後半に、Elasticが、AI時代の波にどのように対応し、進化してきたのかについて軽く見ていきます。 目次 発射台「LLM（大規模言語モデル）」 意味を扱う「ベクトル＆セマンティック検索」 外部知識を統合する「RAG」 自律的に動く「エージェント」 連携を統一する「MCP」 MCPを使う意味 AI同士が協力する「A2Aプロトコル」 なぜA2Aが重要？ Elastic と AI まとめ 発射台「LLM（大規模言語モデル）」 LLMは、与えられた文脈から統計的に「次に来そうな単語」を選ぶことで文章を生成します。つまり、「理解している」のではなく、膨大な学習データの中から最も自然な応答を選び出している仕組みなのです。 GPT‑4o、Claude 3.5 Sonnet、Gemini 1.5 Proなど最新のモデルは、テキストに加えて画像や音声にも対応するマルチモーダル機能を備えています。この進化により、人と自然に対話でき、複雑な状況や文脈も鋭く捉えるようになりました。 ただし、LLMには限界があります。単体では常に最新情報を持つわけではなく、ハルシネーション（誤情報）を出すこともあります。それでも、「すぐに答えが欲しい」「シンプルなチャットやQ&Aで十分」「リアルタイム性やコストを最優先にしたい」といった場面には、非常に頼りになる存在です。 意味を扱う「ベクトル＆セマンティック検索」 LLMの力を支えるのは、「ベクトル化」によって得られる検索精度です。文章や画像、音声などを多次元の数値（ベクトル）に変換し、それらの意味的な「近さ」で関連性を判断できるようにします。たとえば「AIの最新動向」という検索語でも、単語の一致に縛られず、意味的に近い論文や記事を高い精度で抽出できる、これが「セマンティック検索」の肝です。つまり、キーワードが違っても“意味が近ければ見つかる”という価値があり、企業のグローバル知識探索や多言語対応の内部データ検索で特に威力を発揮します。 しかし、KNNによるベクトル検索自体はそこまで新しい話でもありません。では、なぜこれがエージェントの進化に重要な貢献をしたのでしょうか。 セマンティック検索の概念は90年代後半に遡りますが、実用化への道のりは長いものでした。2012年のGoogleによるナレッジグラフの導入で注目を集め、2013年にはWord2Vecがニューラルネットワークを用いた初の単語埋め込み技術として登場しました。この頃からビッグデータの活用が本格化し、大量のデータで言語モデルを訓練できるようになったのです。そして現代的なセマンティック検索は、BERTやTransformerの登場により2018年頃から実用レベルに到達しました。つまり、アルゴリズム的基盤（KNN）は数十年前から存在していたものの、意味理解に必要な高品質な埋め込み技術とコンピューティング能力が揃ったのは比較的最近のことなのです。 外部知識を統合する「RAG」 LLMの弱点を補完するのが「RAG」です。RAG（Retrieval‑Augmented Generation）では、モデルに答えを生成させる前に、外部データベースから関連情報を検索（Retrieval）し、その内容を踏まえて応答（Generation）を構築します。これにより、回答に根拠が加わり、誤情報（ハルシネーション）のリスクを減らすことができます。 さらに進化した「マルチモーダルRAG」では、文章だけでなく画像や音声、動画なども対象に含めて検索・生成ができます。たとえば画像をCLIPでベクトル化し、テキストや映像と一緒に最適な情報を取り出すことが可能です。 こうしたRAGは、専門知識が必要で、常に最新情報を参照したい場合や、回答の品質と信頼性が特に重要な場面で真価を発揮します。つまり、単なるチャットではなく、内容の正確さと根拠を重視する「現場の頼れるAIアシスタント」として活躍します。 自律的に動く「エージェント」 RAGが「正確に答える力」を与える一方、エージェントには「自ら行動する力」が与えられます。つまり、ユーザーの意図を読み取り、最適なツールを選び出し、複数の手順を組み合わせてタスクを自律的に実行する存在です。さらに高度な形として、Agentic RAGでは「検索→生成」という静的な流れにとどまらず、AI自身が動的に検索戦略を立て、文脈を見ながら知識を取得・活用して応答を進化させます。 例えば、 GitHub Copilot の「Agent mode」（VS Code）は、自然言語の指示からコード理解・テスト・修正のループを支援する“自律的な相棒”として進化している。 さらに Copilot agent mode では、VS Code上でコードベースの読み取り、テストの自動実行、エラー修正をループで進行し、自律的なピア・プログラマーとして動作します。 現状では、ツールや仕組みの呼び方が乱立しており、統一された定義がありません。 ここから示すのは、 あくまでも私自身の理解に基づいた整理 です。 AI Agent LLMをコアに、利用可能なツールを呼び出して処理を自動で進める自律的システム。比較的「静的」で、あらかじめ設定された動作に従う存在。 Agentic AI 複数のエージェントがチームのように協力し、異なるLLMや外部リソースとつないで複雑な目標を達成する仕組み。 連携を統一する「MCP」 ここまで、「LLM × 検索」で知識を補強し、「エージェント × ツール」でタスクを自律的に遂行する進化を見てきました。しかし、現場では“どのツールに、どうつなぐのか”が統一されていないという課題があります。そこで登場したのが、MCP（Model Context Protocol）です。 MCPは、エージェントがツールやデータソースに接続するための標準的な「接続口」を提供する、Microsoft Build 2025でも、MCPが「エージェント時代のHTTPのようなプロトコル」として紹介されました。ツールやサービスごとに専用インテグレーションを書かなくても、共通仕様でつなげるようにします。 MCPを使う意味 開発・保守の効率化 ：使用するLLMやツールの数が増えるにつれて発生する、大量のカスタム接続を記述する必要がなくなるため、N×M問題が解消されます。結果として、開発コストを大幅に削減できます。 再利用可能なエコシステム ：一度つなげたツールは、他のエージェントやプロジェクトでもそのまま使えます。更新の波及もスムーズです。 サードパーティとの接続も容易 ：OAuthや認証仕組みを備えた安全で柔軟な接続設計がしやすくなり、導入障壁が下がります AI同士が協力する「A2Aプロトコル」 今や、エージェントがツールに接続する方法が「MCP」で標準化された一方で、エージェント同士の“対話”や“協調”には別の基盤が必要です。そこで注目されるのが、 A2A（Agent‑to‑Agent）プロトコル 。これは、エージェント間の「共通言語」となる通信ルールを定めた仕組みです。 A2Aの主な機能は以下の通りです： Discovery（発見） ：各エージェントが自分の役割やスキルを“Agent Card”として公開し、他のエージェントから見つけられるようになります。 Negotation（交渉） ：どの通信形式（テキスト、フォーム、音声など）や認証方式を使うかを、お互いにすり合わせられます。 Task／State Management（タスク／状態管理） ：タスクの進捗や状態（送信済み・実行中・完了など）をJSON‑RPCやSSEを用いてリアルタイムに共有できます。 Collaboration（協力） ：必要に応じて他のエージェントに処理を依頼し、結果を取得することで、連携した処理が可能になります。 たとえば、旅行手配エージェントが、スケジュール確認を担当するエージェントを見つけてやり取りし、空き時間を確認した上で予約を自動的に確定するような流れが、人の介在なしに完結できるようになります。 なぜA2Aが重要？ 標準化された協調設計 ：各社・各フレームワークで別々に組まれるエージェント連携を、統一された仕様で実現できます。 マルチエージェントの未来が見通せる ：AccentureなどはすでにA2Aをベースに、複数のエージェントが協働する仕組みを導入し始めています。 このように、MCPが「ツールへの接続口を揃える」役割とすれば、A2Aは「エージェント同士の会話や協調を可能にする土台」。それぞれの強みを活かすことで、「ツールを使うエージェント」から「互いに話し合いながらタスクを完遂できるエージェント」へと進化する設計が実現できます。 Elastic と AI 2022年： Elasticsearch 8.0がリリースされ、近似最近傍検索機能と最新自然言語処理モデルのネイティブサポートを搭載。2022年を通して、ベクトル検索はテクニカルプレビューの段階でした。 Elasticsearch 8.4で kNN検索を _search API に統合するなど実運用に向けた大きな前進になり、フィルタリング、再ランキング、レキシカル検索とセマンティック検索を組み合わせたハイブリッド検索が可能になりました。 2023年： Elasticが学習済みスパースモデルELSERを公開。追加学習なしで”意図”に基づくセマンティック検索を実現し、同年の8.9ではRRF（Reciprocal Rank Fusion）によるハイブリッド検索を導入してBM25／ベクトル／セマンティックを安定統合。 2024年： Open/Inference APIを拡充し、OpenAI・Azure・Anthropic・Mistral・Hugging Faceなど外部推論／埋め込み・リランクを公式に統合。RAG実装の柔軟性が大きく向上。 Elastic AI Ecosystemを発表。Elasticsearchベクターデータベースと主要AI企業の事前統合（モデル、クラウド、MLOps、データ準備など）により、RAGアプリ開発の立ち上げと運用投入を加速。Google Cloud／Microsoft／Hugging Face／LangChainなどと連携。 2025年： 社内向けジェネレーティブAIアシスタントElasticGPTを公開。Elasticsearchを中核にしたRAGと観測基盤の組み合わせで、安全で文脈を踏まえた知識探索を従業員に提供。プラットフォーム一体運用の実例に。 セキュリティ領域でのエージェント活用を強化。Elastic AI Assistant for Securityによる自然言語クエリ生成や調査支援、Attack Discoveryによる大量アラートの要約・優先度付けなど、Search AI × RAG × エージェントの実運用を具体化。 現在のポジション: Elasticsearchは2022年8月のバージョン8.4で本格的なベクトルデータベースとして名乗りを上げました。セマンティック検索が主流になってから3-4年遅れでの参入でしたが、既存の大規模ユーザーベースと、従来のBM25検索とベクトル検索を組み合わせたハイブリッド検索機能を武器に、この分野で確固たる地位を築きました。現在、Elasticは「Search AI Platform」として、ベクターDB／ハイブリッド検索（RRF）／リランク／Inference APIを統合し、「見つかる・根拠づける・守る」を土台に、RAGやエージェント実装を本番水準で支える位置づけを確立しています。 まとめ AIアシスタントの進化は、 LLM ：言語を扱う力 セマンティック検索 ：意味を捉える力 RAG ：外部知識を統合する力 エージェント ：自律的に行動する力 MCPとA2A ：連携と協力の力 これらの要素が順に積み重なることで、AIは「人に命令される存在」から「人と一緒に考え、動く存在」へと進化しました。この変化のスピードは早すぎて、今後どんな技術が現れ、私たちの仕事や生活がどう変わるかは、まだ見通しが立ちません。 The post 2025年のAIアシスタント：LLMからAIエージェント（Agentic AI）へ first appeared on Elastic Portal .

キャプションやタグがなくても、テキストで近い画像を検索できる。そんな仕組みを、ElasticsearchとAIを組み合わせ試作しました。画像資産の整理や業務効率化に役立ちます。 Elasticsearch を選んだ理由はシンプルです。 ベクトル検索に強い： 画像やテキストを CLIP で 512 次元ベクトルに変換し、それをそのまま保存して KNN 検索できる。 スケールに強い： 最初は手元の16枚の画像でも、将来的に何千・何万枚に増えても同じ仕組みで動かせる。 検索をカスタマイズできる： 近似検索（速さ）と再ランク（精度）を組み合わせたり、メタデータで絞り込みしたりが簡単。 ※動作環境 Elasticsearch: 8.19.0 Python: 3.11 実装コードとデータセット⇨ 2025-08-image-search ダウンロード 目次 やりたかったこと モデル選びでの失敗と気づき 日本語翻訳の工夫 動かしてみる インデックス作成 データセットの写真 コードの準備 1. 基本設定と依存ライブラリ 2. CLIPのロード 3. 日本語→英語の翻訳 4. ESのインデックス設計 5. 既存の画像をチェック 6. 画像をインデックス 7. 画像検索 なぜ“正規化”が必須？ コマンドラインから実行 検索例と結果 日本語クエリ「池と山」 日本語クエリ「猫とメガネ」 英語クエリ「man and sea」 日本語クエリ「動物園」 まとめ やりたかったこと 画像検索： テキストを入力すると、それに近い画像を探せる 日本語サポート： 日本語で検索しても正しく動く シンプル構成： 余計な仕組みは極力排除して、わかりやすくする モデル選びでの失敗と気づき 試したモデル 最初に試したのは 多言語対応のCLIPモデル ( clip-ViT-B-32-multilingual-v1 ) でした。 CLIP は「画像」と「テキスト」を同じベクトル空間に変換するモデルで、これにより「テキストで画像を探す」「画像に合う説明文を探す」が自然にできます。 ざっくり仕組みを説明すると： 画像エンコーダ：画像を入力して、512次元ほどの数列（＝埋め込み）に変換 テキストエンコーダ：文章も同じ次元の埋め込みに変換 同じ空間で距離を測る：両者が近いほど「意味が似ている」とみなす 問題点 たとえば「ヒマワリ」と「時計」を検索しても、ほぼ同じ結果が返ってきてしまい、 埋め込みの類似度も 0.95〜0.99 と高すぎて区別がつきません。 改善 と課題 精度が低すぎたため、別のモデルを試すことにしました。そこで改めて OpenAIオリジナルのCLIP ( clip-vit-base-patch32) を試してみたところ、こちらであれば納得できる結果が得られそうでした。 物体やシーンを正しく区別してくれる 安定して動作する 日本語は7割程度は理解できない（ 課題！ ） 日本語翻訳の工夫 次の課題は 日本語クエリをどう扱うか でした。 CLIPだけで日本語検索を行うと、正しい結果が返る場合もあれば、外れてしまう場合もありました。これではプロダクション環境で使うには不安定です。 そこで、いくつか方法を試しました。 多言語CLIPをそのまま使う → うまくいかない 手作りの和英辞書を追加 → 手間がかかりすぎる Elasticsearchに翻訳パイプラインを組み込む → 作り込みすぎて保守が大変 最終解決策： LLMを使って日本語クエリを翻訳させる！ 結果的に、この最後の方法が最もシンプルで、しかも精度が良かった。さらに、 gpt-3.5-turbo の 利用コストは非常に低く 、実運用でも十分現実的です。 動かしてみる インデックス作成 画像を data/images/ に入れて次を実行： python smart_clip_search.py index CLIP が画像をベクトルに変換し、Elasticsearch に保存してくれます。 実際のログはこんな感じ↓ (.venv) /path/to/data/code % python smart_clip_search.py index 🔄 Starting image indexing process... This will look at each image and convert it to AI-readable format Loaded CLIP model: openai/clip-vit-base-patch32 Created index: images-openai-only Found 0 already indexed images Found 16 image files 📝 Processing 16 new images ✅ Indexed 1/16: 10-unsplash.jpg ✅ Indexed 2/16: 3-unsplash.jpg ✅ Indexed 3/16: 4-unsplash.jpg ✅ Indexed 4/16: 16-unsplash.jpg ✅ Indexed 5/16: 11-unsplash.jpg ✅ Indexed 6/16: 5-unsplash.jpg ✅ Indexed 7/16: 2-unsplash.jpg ✅ Indexed 8/16: 8-unsplash.jpg ✅ Indexed 9/16: 9-unsplash.jpg ✅ Indexed 10/16: 13-unsplash.jpg ✅ Indexed 11/16: 14-unsplash.jpg ✅ Indexed 12/16: 7-unsplash.jpg ✅ Indexed 13/16: 15-unsplash.jpg ✅ Indexed 14/16: 12-unsplash.jpg ✅ Indexed 15/16: 6-unsplash.jpg ✅ Indexed 16/16: 1-unsplash.jpg 🎉 Indexing complete! Processed 16 new images dev toolで確認すると…　 GET images-openai-only/_count { "count": 16, "_shards": { "total": 1, "successful": 1, "skipped": 0, "failed": 0 } } 確かに16枚、すべて保存されているのがわかります。 一つのドキュメントを例に…　 GET images-openai-only/_doc/loHWwpgBBkwHewC3XB1a { "_index": "images-openai-only", "_id": "loHWwpgBBkwHewC3XB1a", "_version": 1, "_seq_no": 0, "_primary_term": 1, "found": true, "_source": { "image_embedding": [ 0.005093493033200502, 0.004333182703703642, -0.02418620139360428, -0.03343995288014412, ... ], "image_name": "10-unsplash.jpg", "image_path": "/path/to/data/images/10-unsplash.jpg" } } データセットの写真 コードの準備 ここから、コードの説明をします。 1. 基本設定と依存ライブラリ 最初に必要なライブラリを読み込みます。 torch / transformers → CLIPモデルを動かすため PIL → 画像を読み込むため Elasticsearch クライアント → 検索用データベースと接続するため import os, time, torch, numpy as np from pathlib import Path from PIL import Image from transformers import CLIPModel, CLIPProcessor from project_image_search.elastic_client import get_client IMAGE_ROOT = Path("/path/to/data/images") INDEX_NAME = "images-openai-only" .envファイルの最小構成例 ELASTICSEARCH_URL=https://localhost:9200 ELASTICSEARCH_USERNAME=elastic ELASTICSEARCH_PASSWORD=your_password ELASTICSEARCH_CA_CERT=/path/to/ca.crt OPENAI_API_KEY=your_openai_api_key_here 2. CLIPのロード ここで OpenAI が公開している CLIP を読み込みます。 GPU があれば GPU で動かし、なければ CPU で実行します。 def load_clip_model(): model_name = "openai/clip-vit-base-patch32" model = CLIPModel.from_pretrained(model_name) processor = CLIPProcessor.from_pretrained(model_name, use_fast=True) device = "cuda" if torch.cuda.is_available() else "cpu" model.to(device) return model, processor, device 3. 日本語→英語の翻訳 CLIPは英語が得意なので、日本語クエリは GPT で翻訳してから検索。 def translate_with_openai(query: str): # 日本語が含まれていたら OpenAI に翻訳を依頼 4. ESのインデックス設計 Elasticsearch に「画像データを保存する箱」を作ります。保存するのは以下の3つ： 画像の埋め込みをdense_vectorとして（512次元ベクトル） ファイル名 ファイルパス def create_index(): mapping = { "mappings": { "properties": { "image_embedding": {"type": "dense_vector", "dims": 512, "similarity": "cosine"}, "image_name": {"type": "keyword"}, "image_path": {"type": "keyword"} } } } es.indices.create(index=INDEX_NAME, body=mapping) 5. 既存の画像をチェック def get_existing_images(es): res = es.search(index=INDEX_NAME, body={"_source": ["image_path"], "query": {"match_all": {}}}) existing_paths = {hit["_source"]["image_path"] for hit in res["hits"]["hits"]} return existing_paths 既に保存されている画像を重複インデックスしない工夫。 6. 画像をインデックス フォルダ内の画像を読み込み、1枚ずつ CLIP で数値化（埋め込み生成） します。その数値を Elasticsearch に保存することで、後から検索できるようにします。 def index_images(): image = Image.open(img_path).convert("RGB") inputs = processor(images=image, return_tensors="pt").to(device) image_features = model.get_image_features(**inputs) image_features = image_features / image_features.norm(dim=-1, keepdim=True) 7. 画像検索 検索プロセスは大きく5ステップです： 日本語なら英語に翻訳 テキストを CLIP に渡し、埋め込み（512次元ベクトル）に変換 Elasticsearch で「近い画像」を高速に検索（KNN検索） 上位候補を取り出して、再ランク 結果をスコア付きで返す def search_images(query: str, k: int = 5): translated_query = translate_with_openai(query) inputs = processor(text=translated_query, return_tensors="pt").to(device) text_features = model.get_text_features(**inputs) text_features = text_features / text_features.norm(dim=-1, keepdim=True) なぜ“正規化”が必須？ CLIPの出力は512次元ベクトルですが、ベクトルには「方向」と「長さ」があります。 検索で本当に比べたいのは「意味の近さ＝方向」なのに、正規化をしないと「長さの違い」に結果が引っ張られてしまいます。 そのため、全てのベクトルを 長さ1に揃える（正規化） ことで、大きさの違いを無視して「意味の近さ」だけを比べられるようにする必要があります。 コマンドラインから実行 コマンドラインから2つの使い方ができます： index → 画像を読み込んで保存 search <query> → テキストで検索 python smart_clip_search.py index python smart_clip_search.py search "ひまわり" 検索例と結果 いくつか例を見てみましょう。 日本語クエリ「池と山」 python smart_clip_search.py search "池と山" 🔍 Searching for images matching: '池と山' Loaded CLIP model: openai/clip-vit-base-patch32 Translated '池と山' -> 'Lake and mountain' Search Query: 池と山 Translated to: Lake and mountain 1. 6-unsplash.jpg (similarity: 0.228) 2. 3-unsplash.jpg (similarity: 0.205) 3. 2-unsplash.jpg (similarity: 0.190) 4. 7-unsplash.jpg (similarity: 0.187) 5. 10-unsplash.jpg (similarity: 0.177) Low confidence - may not contain '池と山' Total Search Time: 4.904s 結果 →1位はまさに池と山の写真でした。 6-unsplash.jpg 日本語クエリ「猫とメガネ」 python smart_clip_search.py search "猫とメガネ" 🔍 Searching for images matching: '猫とメガネ' Loaded CLIP model: openai/clip-vit-base-patch32 Translated '猫とメガネ' -> 'Cat and glasses' Search Query: 猫とメガネ Translated to: Cat and glasses 1. 13-unsplash.jpg (similarity: 0.294) 2. 9-unsplash.jpg (similarity: 0.253) 3. 11-unsplash.jpg (similarity: 0.169) 4. 7-unsplash.jpg (similarity: 0.141) 5. 10-unsplash.jpg (similarity: 0.133) Medium confidence match Total Search Time: 4.277s 結果 →サングラスをかけた猫の写真が1位に出現。 13-unsplash.jpg 英語クエリ「man and sea」 python smart_clip_search.py search "man and sea" 🔍 Searching for images matching: 'man and sea' Loaded CLIP model: openai/clip-vit-base-patch32 Search Query: man and sea 1. 1-unsplash.jpg (similarity: 0.260) 2. 7-unsplash.jpg (similarity: 0.235) 3. 10-unsplash.jpg (similarity: 0.224) 4. 11-unsplash.jpg (similarity: 0.200) 5. 2-unsplash.jpg (similarity: 0.197) Medium confidence match Total Search Time: 3.058s 結果 → 1位は海辺に立つ男性の写真。英語でも正しい結果が得られました。 1-unsplash.jpg 日本語クエリ「動物園」 python smart_clip_search.py search "動物園" 🔍 Searching for images matching: '動物園' Loaded CLIP model: openai/clip-vit-base-patch32 Translated '動物園' -> 'Zoo' Search Query: 動物園 Translated to: Zoo 1. 15-unsplash.jpg (similarity: 0.260) 2. 13-unsplash.jpg (similarity: 0.205) 3. 5-unsplash.jpg (similarity: 0.199) 4. 3-unsplash.jpg (similarity: 0.194) 5. 10-unsplash.jpg (similarity: 0.156) Medium confidence match Total Search Time: 3.822s 結果 → お見事！１位は確かに動物園の写真でした。 まとめ 今回使った画像データセットは、ファイル名が「1-unsplash.jpg」「13-unsplash.jpg」のように中身が全くわからないもので、写真の説明文も一切ありませんでした。 つまり「テキスト情報ゼロ、画像の中身だけ」という条件です。 それでも CLIP が画像を意味ベクトルに変換し、Elasticsearch が高速に検索してくれたおかげで、 「猫とメガネ」→ サングラス猫の写真 「動物園」→ 動物園の写真 「ひまわり」→ ひまわり畑の写真 と、まさに欲しい画像を返してくれました。 「キャプションなし・タグなし・名前からは何もわからない画像」 を検索できるのは、実務的にも大きなメリットだと思います。 🛠️ トラブルと学び APIキーを入れ忘れる と「No OpenAI API key found」と怒られる “slow image processor”警告 が出るけど、これは無害 インデックスが壊れた時は再作成すればOK 次の一歩 数万枚規模にスケールして性能を検証したい メタデータでフィルタリングを追加してみたい 「画像 → 画像検索」に拡張したい The post Elasticsearch × CLIP × GPTで画像検索システムを作ってみた first appeared on Elastic Portal .

目次 はじめに 対象読者 対象バージョン 検索の準備 1. インデックスの作成 2. インデックスのマッピング設定 3. モデルの準備 4. インジェストパイプラインの作成 5. インジェストパイプラインの確認 6. データの登録 6.1 NDJSONの用意 6.2 一時インデックスへのアップロード 6.3 _reindexの実行 6.4 タスクの完了確認 6.5 _refreshの実行 登録データのストレージ利用量確認 ベクトル検索の実行 rescore_vector を行わないベクトル検索 rescore_vector を行ったベクトル検索 まとめ はじめに 前回 は、Elasticsearchで bbq_hnsw を利用したベクトルの量子化について、その基礎を解説しました。今回は、bbq_hnsw を使って実際にベクトル検索を行う手順を解説します。 対象読者 Elasticsearchでベクトル検索の導入を検討している方 Elasticsearchの初心者〜中級者 対象バージョン Elasticsearch 8.19.0以上 Elasticsearch 9.1.0以上 1 この記事のサンプルでは rescore_vector の oversample に0を指定していますが、これがサポートされているのは上記のバージョン以降です。筆者はElasticsearch 8.19.0で検証しました。 検索の準備 1. インデックスの作成 今回の検証に利用するインデックスを作成します。今回はベクトル検索のみを行うため、形態素解析の設定は省略します。 以下のリクエストをKibanaのDev Toolsから実行してください。 （インデックス名 = waganeko_with_bbq_hnsw） PUT /waganeko_with_bbq_hnsw/ { "settings": { "index": { "number_of_shards": 1, "number_of_replicas": 1, "refresh_interval": "3600s" } } } 2. インデックスのマッピング設定 インデックスにフィールドを作成します。ここでは、以下の3つのフィールドを定義します。 フィールド名 タイプ 説明 chunk_no long チャンク番号 content text 本文 text_embedding dense_vector 384次元のfloat32密ベクトル 上記には bbq_hnsw で量子化された項目を記載していません。 bbq_hnsw による量子化は、厳密にはフィールドではなく、dense_vector タイプのフィールドのindex_optionsとして設定されます。 なお、bbq_hnsw を使ったベクトル検索時のオーバーサンプリング係数は5としています。 現在の最新バージョンでのデフォルト値は3のようですが、ドキュメントに明記されているわけではないため、ご自身のバージョンでご確認ください。 以下のリクエストをDev Toolsから実行します。 PUT /waganeko_with_bbq_hnsw/_mapping { "dynamic": false, "properties": { "chunk_no": { "type": "long" }, "content": { "type": "text" }, "text_embedding": { "type": "dense_vector", "dims": 384, "index_options": { "type": "bbq_hnsw", "rescore_vector": { "oversample": 5 } } } } } dense_vector 型のフィールドの設定については、 公式ドキュメント を参照してください。 3. モデルの準備 テキストから密ベクトルを生成するためのモデルを準備します。 Elasticsearchに内包されているモデルを利用する（例: .multilingual-e5-small_linux-x86_64） または Elasticsearchの外部にあるモデルを利用する（例: OpenAIのtext-embedding-3-small） 筆者は、前者の.multilingual-e5-small_linux-x86_64を利用しました。モデルの準備の詳細な手順は割愛します。 2 4. インジェストパイプラインの作成 準備したモデルを利用するインジェストパイプラインを作成します。 .multilingual-e5-small_linux-x86_64を使う場合の例は以下のとおりです。 PUT /_ingest/pipeline/my-e5-small-pipeline { "description" : "Text embedding pipeline", "processors" : [ { "inference": { "model_id": ".multilingual-e5-small_linux-x86_64", "input_output": [ { "input_field": "content", "output_field": "text_embedding" } ] } } ] } “content” と “text_embedding” は、上で作成したインデックスのフィールド名と一致させてください。 このリクエストをDev Toolsから実行します。 5. インジェストパイプラインの確認 Embeddingモデルとパイプラインが正しく登録できたか確認します。 以下のリクエストをDev Toolsから実行します。 POST /_ingest/pipeline/my-e5-small-pipeline/_simulate { "docs": [ { "_index": "index", "_id": "id", "_source": { "content": "吾輩は猫である" } } ] } 正しく登録できていれば、以下のように384次元のfloat32のベクトルが返却されます。 { "docs": [ { "doc": { "_index": "index", "_version": "-3", "_id": "id", "_source": { "text_embedding": [ 0.06494276970624924, 0.0074624731205403805, ... ] } } } ] } 6. データの登録 今回は、 青空文庫 で公開されている 「吾輩は猫である」 のデータを検証に利用しました。データ登録方法はいくつかありますが、ここでは詳細な手順は割愛し、筆者が行った方法を紹介します。 6.1 NDJSONの用意 検証用のため、青空文庫のデータを1行1チャンクとしました。RAGなどの用途では、より適切なチャンキングを検討してください。 {"chunk_no":1, "content":"一\n吾輩は猫である。名前はまだ無い。"} ... {"chunk_no":2207, "content":"次第に楽になってくる。...ありがたいありがたい。"} 6.2 一時インデックスへのアップロード 作成した NDJSON を Elastic の File Upload 機能を使って一時的なインデックス(waganeko_tmp)へアップロードします。（Data View は作成しません。） 6.3 _reindexの実行 作成したパイプラインを使って、一時インデックス(waganeko_tmp) からwaganeko_with_bbq_hnsw インデックスへ _reindex します。 POST /_reindex?wait_for_completion=false { "source": { "index": "waganeko_tmp" }, "dest": { "index": "waganeko_with_bbq_hnsw", "pipeline": "my-e5-small-pipeline" } } 時間がかかるので、wait_for_completion=false を指定しておきます。 これにより、上記のリクエストを発行すると、taskid が返却されます。 6.4 タスクの完了確認 タスクが完了したか、以下のコマンドで確認します。 GET /_tasks/{taskid} 6.5 _refreshの実行 タスクが completed になったら、インデックスをリフレッシュします。 POST /waganeko_with_bbq_hnsw/_refresh 登録データのストレージ利用量確認 bbq_hnsw を利用する場合、量子化されたベクトルだけでなく、元のベクトルも保存されていると前回説明しました。実際にストレージ利用量を確認してみましょう。 まず、登録されたドキュメント数を確認します。 GET /waganeko_with_bbq_hnsw/_count レスポンス { "count": 2207, ... } 2207件のドキュメント、つまり2207個のベクトルが登録されています。（今回は、1ドキュメント = 1ベクトル としているため。） 次に、インデックスのストレージ利用量を調べます。 POST /waganeko_with_bbq_hnsw/_disk_usage?run_expensive_tasks=true レスポンス { "_shards": { "total": 1, "successful": 1, "failed": 0 }, "waganeko_with_bbq_hnsw": { ... "text_embedding": { ... "knn_vectors_in_bytes": 3577380 } } } knn_vectors_in_bytes に表示された3577380バイトが、ベクトルデータのサイズです。 この値を理論値と比較してみましょう。 項目 値 ベクトルの総数 2207個 次元数 384次元 float32ベクトルの1要素のサイズ 4バイト bbq量子化後のベクトルの1要素のサイズ 1/8バイト 量子化前のサイズと量子化後のサイズを合計すると… 量子化前のサイズ: 2207 * 384 * 4 = 3,389,952バイト 量子化後のサイズ: 2207 * 384 * 1/8 = 105,936バイト 合計: 3,389,952+105,936=3,495,888バイト 実測値の3,577,380バイトと理論値の3,495,888バイトは非常に近い値です。この結果から、インデックス内には量子化前のベクトルと量子化後のベクトルの両方が保存されていると推測されます。 参考までに、他の量子化方法でも計測した結果を記載しておきます。 量子化方法 knn_vectors_in_bytes (実測値) 理論値 量子化なし 3,398,780 3,389,952 bbq_hnsw 3,577,380 3,495,888 int8_hnsw 4,310,912 4,237,440 いずれも、理論値に近い実測値となっています。 ベクトル検索の実行 それでは、いよいよbbq_hnswを使ったベクトル検索を実行してみましょう。 rescore_vector を行わないベクトル検索 まずは、rescore_vector を行わない場合の検索結果を確認します。 検索クエリ: “鏡が持ってこられた場所” 取得件数: 10件 Elasticsearch 8.19.0ではデフォルトで rescore_vector が行われるため、”oversample”: 0を指定して意図的に無効化しています。これはあくまで検証目的であり、通常は推奨されません。 GET /waganeko_with_bbq_hnsw/_search { "_source": false, "fields": [ "chunk_no", "content" ], "knn": { "field": "text_embedding", "query_vector_builder": { "text_embedding": { "model_id": ".multilingual-e5-small_linux-x86_64", "model_text": "鏡が持ってこられた場所" } }, "k": 10, "num_candidates": 100, "rescore_vector": { "oversample": 0 } } } このリクエストを実行した結果が以下です。 rank score chunk_no content 1 0.9310 1472 鏡と云えば風呂場にあるに極まっている。現に吾輩は今朝風呂場でこの鏡を見たのだ。… 2 0.9283 1477 風呂場にあるべき鏡が、しかも一つしかない鏡が書斎に来ている以上は… 3 0.9252 1493 鏡は己惚の醸造器であるごとく、… 4 0.9234 1471 …しかし主人は何のために書斎で鏡などを振り舞わしているのであろう。鏡と云えば風呂場にあるに極まっている。 5 0.9230 1786 「誰が警察から油壺を貰ってくるものか。… 6 0.9228 1458 …図書館もしくは博物館へ馳けつけて、… 7 0.9226 2009 「…僕が昔し姥子の温泉に行って、一人のじじいと相宿になった事がある。… 8 0.9223 1478 …なにさ今鏡を造ろうと思うて一生懸命にやっておるところじゃと答えた。 9 0.9215 1480 かくとも知らぬ主人ははなはだ熱心なる容子をもって一張来の鏡を見つめている。… 10 0.9206 1263 …不用心だって金のないところに盗難のあるはずはない。… 最も関連性の高いと思われるchunk_no = 1477が2位になっており、全体的に検索結果の精度が微妙な印象です。 rescore_vector を行ったベクトル検索 次に、検索結果の上位50件（k(=10) * oversample(=5)）を元のベクトルでrescoreしてみます。rescore_vector を指定することで、元のベクトルを使った再評価が行われます。 GET /waganeko_with_bbq_hnsw/_search { "_source": false, "fields": [ "chunk_no", "content" ], "knn": { "field": "text_embedding", "query_vector_builder": { "text_embedding": { "model_id": ".multilingual-e5-small_linux-x86_64", "model_text": "鏡が持ってこられた場所" } }, "k": 10, "num_candidates": 100, "rescore_vector": { "oversample": 5 } } } ※mappings作成時に “rescore_vector”: { “oversample”: 5 } を指定しているので、本来は省略可能ですが、ここでは、わかりやすいよう明示しています。 rescore_vector の動作: 公式ドキュメント によると、このリクエストを実行した場合、以下の流れで検索が行われます。 (1) 各シャードごとに上位 num_candidates 件（今回は100件）のドキュメントを bbq_hnsw を使って取得します。 (2) そのうち、上位(k × oversample)件（今回は10 * 5=50件）のドキュメントを、元のベクトルを使って再評価（rescore）します。 (3) 再評価されたドキュメントの中から、最終的な上位k件（今回は10件）を取得します。 (4) 複数のシャードがある場合は、(1) – (3) をシャードごとに行い、最終的にマージして上位10件を取得します。今回はシャードが1つなので、この手順は省略されます。 rescore_vector を行った結果が以下です。 rank score chunk_no content 1 0.9288 1477 風呂場にあるべき鏡が、しかも一つしかない鏡が書斎に来ている以上は… 2 0.9248 1493 鏡は己惚の醸造器であるごとく、… 3 0.9219 1480 かくとも知らぬ主人ははなはだ熱心なる容子をもって一張来の鏡を見つめている。… 4 0.9215 1472 鏡と云えば風呂場にあるに極まっている。現に吾輩は今朝風呂場でこの鏡を見たのだ。… 5 0.9214 1786 「誰が警察から油壺を貰ってくるものか。… 6 0.9212 1684 …昨日は鏡の手前もある事だから、おとなしく独乙皇帝陛下の真似をして整列したのであるが、… 7 0.9206 633 「…今日は土曜ですからこれから廻ったら、もう帰っておりましょう。… 8 0.9205 1471 …しかし主人は何のために書斎で鏡などを振り舞わしているのであろう。鏡と云えば風呂場にあるに極まっている。 9 0.9197 1505 …例のごとく赤い手をぬっと書斎の中へ出した。右手に髯をつかみ、左手に鏡を持った主人は、そのまま入口の方を振りかえる。… 10 0.9184 533 行きたいところへ行って聞きたい話を聞いて、舌を出し尻尾を掉って、髭をぴんと立てて悠々と帰るのみである。… 検索結果を見ると、最も関連性の高いドキュメント(chunk_no = 1477)が1位に上がっています。他のドキュメントも、rescoreなしの場合と比べて、より関連性の高いものが上位に来ている印象です。 この結果から、bbq による量子化を行った場合でも rescore_vector を使用することで、良好な検索結果が得られることがわかります。 なお、ベクトル値を再評価する方法は、rescore_vector 以外にも rescore セクションを指定する方法などがあります。詳しくは 公式ドキュメント を参照してください。 まとめ bbq_hnsw で密ベクトルを格納した場合、インデックス内には量子化前のベクトルと量子化されたベクトルの両方が保持されていることを実測値と理論値の比較で確認しました。 bbq_hnsw を利用した密ベクトル検索では、 rescore_vector を使うことで、検索精度を向上させられることを実証しました。 Elasticsearch 9.1.0 は、デフォルトで directio を使用する、という仕様になっています。bbq_hnsw を利用時でメモリが十分に足りている場合は directio を使用しない方がいいケースもあるため、directio を使用しないよう設定する、あるいは Elasticsearch 9.1.1 以上へバージョンアップする、なども検討してみてください。 – https://www.elastic.co/docs/release-notes/elasticsearch/known-issues#elasticsearch-9.1.0-known-issues – https://www.elastic.co/search-labs/blog/knn-vector-search-rescoring-direct-io ↩︎ .multilingual-e5-small_linux-x86_64 を利用する準備の手順は、下記を参考にしてください。 https://elastic.sios.jp/blog/preparing-for-vector-search/ ↩︎ The post Elasticsearchの bbq_hnsw を使ったベクトル検索（実践編） first appeared on Elastic Portal .

目次 はじめに 対象読者 対象バージョン 量子化を利用しない密ベクトル検索 量子化を行わない場合のストレージ ベクトル検索に必要なメモリ量 量子化を利用した密ベクトル検索 量子化の種類 量子化を行う場合のストレージ ベクトル検索に必要なメモリ量 量子化のメリット・デメリット メリット デメリット まとめ 次回予告 はじめに Elasticsearchで密ベクトル検索を行う場合、Elasticsearch 9.0から bbq_hnsw を使った検索がデフォルトになりました。 このブログでは、 bbq_hnsw の基礎について解説します。 対象読者 Elasticsearchでベクトル検索を始める予定の方 Elasticsearchの初心者～中級者 対象バージョン Elasticsearch 8.x（8.18.0以降、bbqとrescore_vectorが利用可能なバージョン） Elasticsearch 9.x 量子化を利用しない密ベクトル検索 まず、量子化を行わない密ベクトル検索について考えてみましょう。 Elasticsearchで密ベクトル検索を行う場合、通常は検索対象となるテキストの float32 ベクトルを格納します。 量子化を行わない場合のストレージ 密ベクトルの量子化を行わない場合、Elasticsearchのストレージには、主に以下のデータが格納されます。 ドキュメントのテキストデータ（text、keyword、longなど） ドキュメントをキーワード検索するための転置インデックス float32型の密ベクトル （上記は簡略化した内容です） 超概略図（レプリカは考慮していません） ベクトル検索に必要なメモリ量 量子化を行わない密ベクトル検索では、全ベクトルのデータをメモリ上に保持して検索を行います。これにより、高速なベクトル検索が可能になります。 では、float32型の密ベクトルを使う場合に、どのくらいのメモリが必要になるか概算してみましょう。 例：検索対象の密ベクトルの総数 = 1億個、次元数 = 2048の場合 ベクトルの1要素は、4バイト(float32)なので、 必要なメモリサイズ（概算）=1億個 * 2048 * 4バイト = 1億個 * 8192バイト = 約800GB この場合、密ベクトル検索には約 800GB のRAMが必要となります。これは非常に大きなメモリ量です。 量子化を利用した密ベクトル検索 次に、ベクトルを量子化して密ベクトル検索を行う場合を考えます。 量子化を一言で説明すると、 ベクトルの圧縮  です。 量子化の種類 圧縮の度合いに応じて、いくつかの量子化手法があります。Elasticsearchでは数種類の量子化を利用可能です。 詳細は、 Elasticsearchの公式ドキュメント をご覧ください。 int8: 1つのベクトル要素を1バイトで表現します。（従来のElasticsearchのデフォルト） int4: 1つのベクトル要素を1/2バイトで表現します。 bbq: 1つのベクトル要素を1ビット（1/8バイト）で表現します。（Elasticsearch 9.0以降のデフォルト） bbqについての詳細は、 Better Binary Quantization in Lucene and Elasticsearch をご覧ください。 量子化を行う場合のストレージ 量子化を行う場合、Elasticsearchのストレージには、元のデータに加えて量子化された密ベクトルが追加で格納されます。 ドキュメントのテキストデータ（text、keyword、longなど） ドキュメントをキーワード検索するための転置インデックス float32型の密ベクトル 量子化された密ベクトル 超概略図（レプリカは考慮していません） このため、量子化された密ベクトルの分だけストレージサイズは大きくなりますが、このデメリットを上回る大きなメリットが得られます（後述）。 ベクトル検索に必要なメモリ量 量子化を行った場合、元のベクトルデータをすべてメモリ上に保持する必要はありません。その代わりに、圧縮された全ベクトルデータをメモリ上に保持します。 量子化の種類によって必要なメモリサイズは異なりますが、ここでは bbq を使った場合で計算してみましょう。 bbq 量子化を行った場合のメモリサイズは、以下の計算式で求められます（条件は、前述と同じく1億件で384次元とします）。 メモリサイズ=1億個 * (2048/8 + 14) + 1億個 * 4 * 16 = 334億バイト = 約 32.6GB この計算式は Elasticsearchの公式ドキュメント に記載されています。 量子化しない場合に必要なメモリが 800GB だったのに対し、bbqを使えばわずか 32.6GB に抑えられます。これは驚くべき削減効果です。 量子化のメリット・デメリット メリット 検索に必要なメモリ量を大幅に削減できます。 検索処理に必要なCPUリソースも削減できます。 デメリット 量子化されたベクトルの分だけ、ストレージの消費量が増えます。 ベクトルを圧縮するため、検索精度がわずかに低下する可能性があります。 この検索精度の低下を抑えるために、Elasticsearchでは、量子化されたベクトルで検索を行った後、検索結果の上位n件に対して量子化前のfloat32ベクトルを使って再検索を行う機能を提供しています。 詳細は、 Dense Vector kNN Search Rescoring をご覧ください。 bbq量子化を利用する場合、再検索は本来取得したい件数の3〜5倍の検索結果に対して行うことが推奨されています。 なお、 int8 量子化の場合、再検索の必要性はそれほど高くないとされています。 まとめ ここまでの内容を整理しましょう。 Elasticsearchは、密ベクトル検索において量子化によるメモリ削減を推奨しています。 Elasticsearch 9.0からは、密ベクトル検索のデフォルトとして bbqによる量子化 が採用されました。 Elasticsearchで検索用に密ベクトルを保持する場合、ストレージには float32ベクトルと量子化されたベクトル（bbqなど）の両方 が格納されます。 bbqで量子化されたベクトルを使って検索する場合、必要なメモリ量は、元のベクトルをそのまま使う場合に比べて大幅に削減されます。 bbqで量子化されたベクトルを使う場合、検索精度の低下を防ぐために、上位n件に対して元のベクトルを使った再検索を行うことが推奨されます。推奨されるnの値は、取得したい件数の3〜5倍です。 次回予告 次回は、実際にbbqベクトルを使った密ベクトル検索を試してみましょう。 The post Elasticsearh の bbq_hnsw について（基礎編） first appeared on Elastic Portal .

目次 はじめに 対象読者 Elastic 認定試験 Elastic Security for SIEM のトレーニングコース トレーニング用 Kibana 画面へのアクセス方法 Lab 環境の開始 lab-machine の bash 画面とURLの確認 CREDENTIALS の取得 Lab 環境のURLへアクセス Kibana 画面へのログイン Kibana の Home 画面の表示 演習問題の表示 CTFd の URL の取得 CTFd へのアクセス 初回登録手順 ログイン（２回目以降） CTFd のトップメニュー 演習問題の表示 Challenge 一覧画面 回答入力画面のロック解除 回答入力画面 Windows-Endpoint Windows-Endpoint Windows 環境へのコピー&ペースト まとめ はじめに 今回は、Elastic Certified SIEM Analyst のトレーニングコースの Lab 環境について、その特徴と具体的な操作方法を紹介します。 （Elastic Certified SIEM Analyst の Lab 環境は、従来のトレーニングコースの Lab 環境とは操作方法が異なりますので、ご注意ください。） 対象読者 Elastic Certified SIEM Analyst のトレーニングコースの受講を検討している方 Elastic Certified SIEM Analyst のトレーニングコースの受講を始めたばかりで、Lab 環境の操作に戸惑っている方 Elastic 認定試験 これまで Elastic に関する認定試験には3種類の試験がありました。 Official Certification for Users of Elasticsearch and Kibana You mastered Elasticsearch, now it's time to enhance your professional visibility and grow opportunities for your compan... www.elastic.co Elastic Certified Engineer Elastic Certified Analyst Elastic Certified Observability Engineer ここに、先日、Elastic Certified SIEM Analyst が追加されました。 Elastic Security for SIEM のトレーニングコース Elastic Certified SIEM Analyst の認定試験のためのトレーニングとして、「Elastic Security for SIEM」トレーニングコースも追加されました。 Elastic Security for SIEM www.elastic.co Elastic Security for SIEM のトレーニングコースには、Virtual と On-Demand の2つの形式が用意されています。On-Demand コースは、 プロモーションとして2025年10月31日まで無償で受講できます 。 On-Demand コースの中には実際に Elastic の画面を操作して体験できる Lab 環境が用意されています。しかし、この Elastic Security for SIEM のコースが比較的新しいためか、これまでのトレーニングコースの Lab 環境とは操作方法が少し異なります。 トレーニング用 Kibana 画面へのアクセス方法 Lab 環境の開始 Elastic Security for SIEM のトレーニングコースを開始して進めていくと、次のような画面が表示されます。 ここまでは、従来のトレーニングコースと同じく、[LAB] をクリックします。 lab-machine の bash 画面とURLの確認 さきほどの [LAB] をクリックすると、次のような画面が表示されます。 ここが従来のトレーニングコースとは異なる点です。従来は、[Terminal] や [Editor] の隣に [Kibana] などが用意されていましたが、このコースでは Lab 環境の URL が表示されます（赤枠部分）。このURLを 必ずコピーしておきましょう 。 CREDENTIALS の取得 bash 画面から次のコマンドを実行してください。 cat CREDENTIALS すると、CREDENTIALS の内容が表示されます。 この内容も コピーしておいてください 。Kibana へのログイン時に必要となります。 Lab 環境のURLへアクセス 先ほどコピーした URL を、Web ブラウザの新しいタブに入力しアクセスします。 接続に成功すると、次の画面が表示されます。 ここで Kibana をクリックします。 Kibana 画面へのログイン Kibana のログイン画面が表示されます。 ここに、先ほどコピーした CREDENTIALS の内容を入力します。 Username: elastic Password: “…” で囲まれて表示された内容 Kibana の Home 画面の表示 ログインに成功すると、Kibana の Home 画面が表示されます。 ※注意点　Elastic Security for SIEM のトレーニングの Lab 画面を表示していない状態で、URL に直接アクセスしてログインしようとしても、この画面は表示されません。必ず Elastic Security for SIEM のトレーニングの Lab 画面を表示している状態でアクセスしてください。 演習問題の表示 Elastic Security for SIEM には演習問題が用意されています。その演習問題の表示方法もこれまでのトレーニングコースとは異なり、”CTFd”というプラットフォームを利用して、演習問題の表示や回答の入力を行います。 CTFd の URL の取得 lab-machine の bash を表示している画面の左上から [CTFd] を選択します。 すると、画面が CTFd の bash に切り替わります。 ここの URL を コピーしておきましょう （赤枠部分）。 CTFd へのアクセス 先ほどコピーした URL をWebブラウザの新しいタブへ入力し、アクセスします。 成功すると、以下の画面が表示されます。 初回登録手順 初回アクセス時は、上記の画面の Register をクリックし、初回登録画面へ進みます。 必要事項を入力して [Submit] をクリックして、登録を完了させます。 ログイン（２回目以降） 2回目以降は、Login をクリックしてログイン画面へ進みます。 必要事項を入力して、 [Submit] をクリックします。 CTFd のトップメニュー ログインに成功すると、Challenge の一覧が表示されますが、この時点ではまだ Challenge ボタンは操作しないでおきましょう。 演習問題の表示 さきほどの上部のメニュー内の Lab Guide をクリックすると、演習問題の一覧が表示されます。 この画面内のリンクをクリックすると、さらに詳細画面へ遷移し、具体的な演習内容が表示されます。 Challenge 一覧画面 上部のメニューの Challenges をクリックすると、Challenge の一覧画面に戻ります。 ここから、各演習問題の回答を入力していきますが、最初は、ロックされていて回答を入力することはできません。 回答入力画面のロック解除 例として、3.1 のボタンをクリックしてみます。 キーの入力欄が表示され、正しいキーを入力しないと、ロックが解除されません。 このキーは、Elastic Security for SIEM のテキスト内に記載されています。3.1 のキーは、3.1 章のテキストの終わり頃に記載されています。記載されているキーを入力して、 [Submit] をクリックします。 正しいキーを入力すると、上記のように、3.1 の中の各回答入力用ボタンが表示されます。 回答入力画面 例として、3.1 の 1 のボタンをクリックしてみます。 問題の内容と、回答入力欄が表示されます。回答を入力して [Submit] を押すと、回答の正誤が判定され採点されるものと思われます（筆者も、まだそこまで進んでいません）。 Windows-Endpoint Windows-Endpoint Lab 環境には Windows Endpoint が含まれています。Lab 環境内の Windows Endpoint を開くには、lab-machine の bash を表示している画面の左上から [Windows-Endpoint] を選択します。 Windows Endpoint 画面が表示されます。 Windows 環境へのコピー&ペースト 前述の操作で、Windows 環境が表示されるのですが、デフォルトの状態では Windows 環境へのコピー＆ペーストができません。 （指示の一部には、Kibanaの操作画面からコマンドをコピーして、それをペーストするよう指示されているものがあります。） ※注意事項　操作には、 Chrome を使用してください。他のWebブラウザでは確認できていません。 Windows 環境へコピー＆ペーストできるようにします。 Windows-Endpoint の右側に歯車アイコンがありますが、さらにその右にクリップボードのアイコンがあります。これをクリックします。すると Lab クリップボードの画面が開きます。 この Lab クリップボードを経由して、コマンドなどを張り付けるのですが、そのままでは操作できません。 右下の Learn how をクリックします。すると次のダイアログが表示されます。 上部の Open Chrome’s clipboard permission dialog をクリックします。 すると、次のポップアップが表示されます。 ここで、[許可する] をクリックしてください。 （※要は、app.strigo.io からのクリップボードへのアクセスを許可する必要があります。） これで、Kibanaの操作画面　→　Lab クリップボード　→　Windows内のPowershell　のように、Lab クリップボードを経由することで、コピー＆ペーストができるようになります。 まとめ Elastic Security for SIEM のトレーニングコースの Lab 環境の雰囲気や、おおよその操作方法を理解していただけたでしょうか。 繰り返しになりますが、On-Demand コースは、 2025年10月31日まで無料で受講できます ので、この機会に受講を検討してみてはいかがでしょうか？ The post Elastic Security for SIEM のトレーニング用Lab環境の解説 first appeared on Elastic Portal .

「社内のドキュメントを、ChatGPTのように対話形式で検索できたら…」 「ノーコードツールでプロトタイプを作りたいけど、検索精度が物足りない…」 そんな悩みを抱える業務改善担当者の方へ。本記事では、オープンソースのワークフロー自動化ツール n8n と、強力な検索エンジン Elasticsearch を組み合わせ、実用的な RAG システムを構築する方法を説明します。 完成後のAIチャットボットが、以下のようなものになります。 データ検索: 映画のタイトル、監督、ジャンル、あらすじなど、複数の要素を横断して検索します。 自然言語での対話: 「アクション映画でおすすめは？」といった曖昧な質問にも的確に応答します。 会話記憶: 文脈を理解した、人間らしいスムーズな対話を実現します。 目次 なぜこの技術スタックなのか？n8n, Elasticsearch, LLMの強力なシナジー その前に：n8nとは？ 必要な準備 n8nの使い方: 最初のステップ クラウド版 セルフホスト版 今回構築したワークフロー  パート1：セットアップフロー（データベース構築） 1. Setup Trigger（セットアップトリガー） 2. Check Index Exists（インデックス存在確認） 3. Index Exists?（条件分岐） 4. Delete Existing Index（既存インデックス削除） 5. Create Index（インデックス作成） 6. Load CSV Data（CSVデータ読み込み） 7. Extract CSV Data（CSV解析） 8. Index Movie Data（映画データインデックス化） 9. Setup Complete（セットアップ完了） パート2：チャットボットフロー（実際の検索・応答） 10. When chat message received（チャットメッセージ受信） 11. Movie Expert AI（AI エージェント） 12. OpenAI Chat Model（言語モデル） 13. Movie Search Tool（映画検索ツール） 14. Conversation Memory（会話記憶） 15. Format Response（レスポンス整形） 作成手順のまとめ ステップ1：環境準備 ステップ2：認証情報の設定 ステップ3：セットアップフローの構築 ステップ4：チャットボットフローの構築 ステップ5：接続とテスト トラブルシューティング よくある問題と解決策 1. Elasticsearch接続エラー 2. CSVファイル読み込みエラー 3. OpenAI API呼び出しエラー 4. 日本語文字化け 機能拡張のアイデア 参考リンク なぜこの技術スタックなのか？n8n, Elasticsearch, LLMの強力なシナジー このシステムの中核をなすのが「RAG」という考え方です。これは、外部の知識データベースから関連情報を「検索（Retrieve）」し、その情報を基に大規模言語モデル（LLM）が回答を「生成（Generate）」する技術です。これにより、LLMが元々知らない情報（例：自社データ）についても、正確な回答が可能になります。 今回の構成では、各ツールがRAGにおいて完璧な役割分担を果たします。 Retriever (検索役): Elasticsearch Generator (生成役): OpenAI (GPT-3.5/4) Orchestrator (指揮者): n8n これら3つを繋ぎ合わせ、データの前処理からユーザーとの対話まで、一連の流れを 自動化 するのがn8nの役割です。ノーコード／ローコードの直感的なUIで複雑なロジックを組める柔軟性が、今回のシステム構築を可能にします。 その前に：n8nとは？ ここまでn8nという名前が当たり前のように出てきましたが、ここで改めてその正体と、なぜ今多くの技術者から注目されているのか、その魅力について説明します。 n8n（エヌ・エイト・エヌ 「nodemation」の略 ）は、 2019年に誕生した オープンソースのワークフロー自動化ツールです。 一言でいえば、様々なデジタルサービスやツールを、まるでパズルのピースをはめ込むように自由に組み合わせて、定型業務を自動化できるプラットフォームです。 n8nが他のツールと一線を画し、技術者・非技術者にとって強力な武器となる理由は、主に以下の3点に集約されます。 オープンソースによる柔軟性とコントロール ：n8nは、クラウド版とセルフホスト版から選択可能です。 ノーコードとプロコードの融合 ：ドラッグ＆ドロップで簡単に自動化でき、JavaScriptやPythonでの拡張も可能です。 豊富な接続性 ：数百種類のサービス（Gmail、Slack、Notionといった日常的なツールから、AWS、Google Cloud、MCPまで）に対応し、インテリジェントなシステム構築を可能にする「司令塔」として機能します。 単純作業の 自動化 で時間を生み出すだけでなく、今回のように複数の高度な技術を連携させ、新たな価値を創造する。n8nは、そんな「攻めの自動化」を実現するためのプラットフォームなのです。 この強力な自動化ツールを指揮者として、いよいよ具体的なシステム構築に入っていきましょう。 必要な準備 n8n（今回のバージョン；セルフホストv.1.97.1） Elasticsearch（今回のバージョン；9.0.3） OpenAI API（GPT-3.5/4） CSVファイル（映画データ：LLMを使用して、架空の映画のcsvのデータセットを作成した。カラムはタイトル、ジャンル、監督、作成年、映画紹介となります。９０編の映画の情報が入っています。） n8nの使い方: 最初のステップ n8nを始めるための具体的な手順を、クラウド版とセルフホスト版それぞれについて説明します。 クラウド版 一番手軽に始める方法です。公式サイトからサインアップすれば、すぐに利用を開始できます。 14日間の無料トライアル が提供されています。まずは 公式サイト にアクセスし登録してみましょう。 トライアル期間終了後の料金プランは公式サイトでご確認ください。2025年7月23日現在の料金プランは以下の通りです。 セルフホスト版 ご自身のPCやサーバーでn8nを動かす方法です。 前提条件: PCに Node.js がインストールされている必要があります。 インストール: ターミナル（コマンドプロンプト）を開き、以下のコマンドを実行するだけでn8nがダウンロードされます。 npx n8n 起動: ダウンロード後、同じくターミナルで以下のコマンドを実行します。 n8n 起動が完了すると、ブラウザで http://localhost:5678/ にアクセスすることでn8nの画面を開くことができます。 この記事ではn8nの詳細な使用方法については触れませんが、後の手順でスムーズに進められるよう、主要な画面について簡単に説明します。 起動後、何もないキャンバスが表示されます。画面中央または右上のプラスアイコンをクリックしてノードを選択します。 右側からノードリストが表示されます。 検索欄から目標のものを検索できます。 ターゲットのノードをキャンバスにドラッグ＆ドロップします。 プラスのマークをクリックして次のノードに繋げます。まだ設定が完了していないので赤いマークが表示されている。 ノードをダブルクリックすると設定画面が開きます。後ほど説明します。 今回構築したワークフロー  このワークフローは、CSVファイルから映画データを読み込み、Elasticsearchに保存し、OpenAI GPTを活用した自然言語での映画検索を可能にします。 大きく分けて2つの部分で構成されています： パート1：セットアップフロー（データベース構築） まず、AIの知識源となる映画データをElasticsearchに投入（インデックス）します。 こちらのワークフローの目的は、CSVデータを読み込み、いつでも検索できる形でElasticsearchに保存することです。主に「①CSV読み込みと整形」「②Elasticsearchへの登録」というステップで構成されます。 1. Setup Trigger（セットアップトリガー） 役割 ：ワークフローを手動で開始するトリガー ノード ：Manual Triggerを使用 2. Check Index Exists（インデックス存在確認） 役割 ：Elasticsearchに「movies3」という名前のインデックスが既に存在するかチェック ノード ：HTTP Request 設定詳細 ： メソッド：HEAD URL：https://localhost:9200/movies3 認証：Basic認証（Elasticsearchの認証情報） Basic AuthのプールダウンからCreate new credentialを選びます。 elasticのIDとパスワードを入力します。画面の左上をダブルクリックするとノード名が変えられます。 今回、設定を簡単にするためにIgnore SSLを使いました。画面下のAdd optionをクリックすると選択できます。 Parametersタブ以外にSettingsタブもありますが今回は使用しません。 3. Index Exists?（条件分岐） 役割 ：インデックスの存在状況に基づいて処理を分岐 ノード： IF 設定 ：条件判定 条件 ：$response.statusCode == 404（存在しない場合） 分岐 ： True（存在しない）→ 新規作成へ False（存在する）→ 削除してから新規作成へ ※設定画面を閉じたい場合、黄色のエリアをクリックします。 4. Delete Existing Index（既存インデックス削除） 役割 ：既存のインデックスを削除 ノード ：Elasticsearch 設定 ： リソース：Index オペレーション：Delete インデックスID：movies3 5. Create Index（インデックス作成） 役割 ：新しいElasticsearchインデックスを作成 ノード：Elasticsearch 設定 ： リソース：Index オペレーション：Create インデックスID：movies3 6. Load CSV Data（CSVデータ読み込み） 役割 ：ローカルファイルからCSVデータを読み込み ノード ：Read/Write File 設定 ： ファイルパス：/Users/※※※/n8n/映画情報.csv　（ファイルパスは自分の環境に合わせて変更が必要です） データプロパティ名：data 7. Extract CSV Data（CSV解析） 役割 ：読み込んだCSVファイルを構造化データに変換 ノード ：Extract from File 設定 ：Raw Dataを無効化してJSONとして解析 8. Index Movie Data（映画データインデックス化） 役割 ：解析したCSVデータをElasticsearchに保存 ノード ：Elasticsearch 設定詳細 ： オペレーション：Create インデックスID：movies3 フィールドマッピング： タイトル ← CSVのタイトル列 監督 ← CSVの監督列 映画紹介 ← CSVの映画紹介列 作成年 ← CSVの作成年列 ジャンル ← CSVのジャンル列 9. Setup Complete（セットアップ完了） 役割 ：セットアップの完了状況を記録 ノード ：Set 出力 ：完了メッセージとインデックス化されたレコード数 これで最初のフローが完成しました。 右下にある緑の✅がうまく動いていたとの意味になります。 パート2：チャットボットフロー（実際の検索・応答） 次に、ユーザーからの質問にAIが答えるためのフローを構築します。 このワークフローの目的は、ユーザーの質問をトリガーに、LangChainのAIエージェントが自律的に思考・行動し、最適な回答を返すことです。AIエージェントは、必要に応じて専用検索ツール、Elasticsearch を呼び出し、関連情報を取得します。 10. When chat message received（チャットメッセージ受信） 役割 ：ユーザーからのチャットメッセージを受信するトリガー ノード ：Chat Trigger 設定 ：メッセージを受信 11. Movie Expert AI（AI エージェント） 役割 ：チャットボットの中核となるAIエージェント ノード ：AI Agent システムメッセージ 12. OpenAI Chat Model（言語モデル） 役割 ：自然言語理解と生成を担当 ノード ：OpenAI Chat Model　 設定 ： モデル：gpt-3.5-turbo 最大トークン：1000 温度：0.7（創造性のバランス） Credential to connect withからCreate new credentialを選んでOpenAIのAPIを入力する必要があります。 13. Movie Search Tool（映画検索ツール） 役割 ：Elasticsearchでの映画検索を実行 ノード ：HTTP Request Tool 検索クエリの詳細 ： { "query": { "bool": { "should": [ { "multi_match": { "query": "{{ $parameter.searchText }}", "fields": [ "タイトル^3", "監督^2", "ジャンル^2", "映画紹介^1" ], "type": "best_fields", "fuzziness": "AUTO", "operator": "or" } }, { "wildcard": { "タイトル.keyword": "*{{ $parameter.searchText }}*" } } ] } } } 検索の特徴 ： bool / should: ここに含まれる条件のいずれかに一致すれば結果として返されます。「OR検索」のような振る舞いをし、検索の網羅性を高めます 。 multi_match: ユーザーからの検索語 {{ $parameter.searchText }} を、複数のフィールド (タイトル, 監督など) に対して同時に検索します 。 fields とブースト (^3) : ここがチューニングの要です。「タイトル」フィールドの重要度を3倍、「監督」「ジャンル」を2倍にしています 。これにより、検索語が紹介文に含まれるだけの映画よりも、タイトルそのものに含まれる映画が、より関連度が高いと判断され、検索結果の上位に表示されます。 fuzziness: “AUTO”: ユーザーが多少タイポしても（例：「インターステラ」を「インタステラー」と入力）、Elasticsearchが賢く解釈して正しい映画を見つけてくれます 。 wildcard: multi_matchが単語単位での検索なのに対し、こちらは部分一致を可能にします 。例えば「スター」と検索すれば「スター・ウォーズ」がヒットするようになります。このように性質の異なる検索方法を should で組み合わせることで、検索の精度と網羅性を両立させています。 size: 5 : 検索結果を最大5件に絞り込み、LLMに渡す情報量を適切にコントロールします 。 14. Conversation Memory（会話記憶） 役割 ：対話の文脈を記憶・維持 ノード ：Memory Buffer Window 設定 ：セッションキー「movie-chat-session」で会話を識別 15. Format Response（レスポンス整形） 役割 ：AIの回答を整形して返す ノード ：Set 出力項目 ： response：AIの回答 timestamp：回答時刻 status：処理状況 clean_output：整形済み回答 これで最後のフローが完成しました。 右下にある緑の✅がうまく動いていたとの意味になります。 左下の黄色の点線が質問を書くとこになります。 作成手順のまとめ ステップ1：環境準備 n8nをインストール・起動 Elasticsearchをインストール・起動 OpenAI APIキーを取得 映画データCSVファイルを準備 ステップ2：認証情報の設定 n8nの「Credentials」でElasticsearch認証情報を作成 OpenAI API認証情報を作成 HTTP Basic認証情報を作成 ステップ3：セットアップフローの構築 Manual Triggerノードを配置 HTTP Requestノードで存在確認を設定 IFノードで条件分岐を作成 Elasticsearchノードでインデックス操作を設定 ファイル読み込み・解析ノードを配置 データインデックス化ノードを設定 ステップ4：チャットボットフローの構築 Chat Triggerノードを配置 LangChain AgentノードでAIエージェントを設定 OpenAI Chat Modelノードを接続 HTTP Request Toolで検索機能を実装 Memory Buffer Windowで記憶機能を追加 Setノードで回答整形を設定 ステップ5：接続とテスト 全ノードを適切に接続 セットアップフローを実行してデータを投入 チャットボットをテストして動作確認 トラブルシューティング よくある問題と解決策 1. Elasticsearch接続エラー 症状 ：「Connection refused」エラー 解決策 ：Elasticsearchが起動しているか確認、URLとポート番号を確認 2. CSVファイル読み込みエラー 症状 ：「File not found」エラー 解決策 ：ファイルパスを正しく設定、ファイルの存在を確認 3. OpenAI API呼び出しエラー 症状 ：「Unauthorized」エラー 解決策 ：APIキーが正しく設定されているか確認 4. 日本語文字化け 症状 ：日本語が正しく表示されない 解決策 ：CSVファイルの文字エンコードをUTF-8に設定 機能拡張のアイデア このシステムは出発点ですが、さらに進化させることも可能です。 ベクトル検索への移行: 今回はキーワードベースの検索が中心でしたが、Elasticsearchのベクトル検索機能を活用すれば、「宇宙がテーマの壮大な映画」のような、より抽象的な意味での類似映画検索が可能になります。 Kibanaでの可視化連携: Elasticsearchとセットで使われる可視化ツールKibanaを連携させれば、「年代別の映画ジャンル構成」などをダッシュボードで分析できます 。 音声入力対応: n8nのWhisperノードなどを組み合わせれば、音声で質問できるチャットボットへの拡張も夢ではありません 。 MCP（Model Context Protocol）の導入 n8n は MCP クライアント／サーバー機能をベータ公開しており、AI エージェントが外部ツールや n8n の別ワークフローを連携しやすくなっています。 たとえば、Elasticsearch 検索後に別のデータベースをGPTに問い合わせたり、Slack通知やファイル出力ワークフローを「AI による判断で自動実行」するといった高度な連携がノーコードで可能です。 私もこのプロジェクトは初めてのトライでしたが、まず基本的な構成で動作させてから、段階的に機能を追加していくことをお勧めします。このチャットボットをベースに、様々な分野のデータベース検索システムに応用することが可能です。 参考リンク n8n公式ドキュメント https://github.com/n8n-io/n8n Elasticsearch公式ガイド 　　Elasticの14日間無料期間もあります。 OpenAI API ドキュメント LangChain ドキュメント 映画情報ダウンロード（CSV） The post ローコードRAG構築：n8nとElasticsearchで作るAI検索チャットボット first appeared on Elastic Portal .

Elasticsearchの標準アナライザーは  Kuromoji  ですが、他にも日本語向けのアナライザーが存在します。本記事では  Sudachi  や  MeCab 、およびPythonライブラリの  Janome 、そして  LLM（GPT-4）  といった選択肢を比較し、どんな場面でどれを使うべきかを検討しました。 なお、Elasticsearch 9.xではSudachiやMeCabの公式対応プラグインはまだリリースされていません。そのため今回は  Python環境で事前に形態素解析してからElasticsearchにインデックスする方法 を採用しています。一方、Janomeは純Python実装であるため、追加プラグインなしで使用可能です。 目次 比較対象アナライザー ステップ0：事前準備 Python環境とテキスト設定 トークン正規化・クリーニング関数 比較戦略 トークン化関数の定義（共通フォーマット出力） 包括的トークナイザー比較分析 📊 Kuromoji（ベースライン）出力 📊 Sudachi A/B/C、MeCab、Janome、GPT-4 出力 分析結果サマリー・統計表 1. トークン数比較表 2. ユニークトークン分析 考察 まとめ 比較対象アナライザー 1. Elasticsearchプラグイン系 　　 Kuromoji ：Elasticsearch標準の日本語アナライザー 2. Pythonライブラリ系（アプリ側で事前解析） SudachiPy ：3種類の粒度（A/B/C）に対応 MeCab ：高速かつ実績豊富な形態素解析器 Janome ：Pure Pythonで導入が簡単 3. LLM系（外部API） 　　 OpenAI GPT-4o ：文脈を考慮した柔軟な分割が可能 ステップ0：事前準備 1. 仮想環境の作成（uvを使用） curl -LsSf https://astral.sh/uv/install.sh | sh mkdir analyzer-project && cd analyzer-project uv venv source .venv/bin/activate 2. 必要なPythonライブラリのインストール uv pip install elasticsearch janome openai sudachipy sudachidict_core mecab-python3 3. Elasticsearchプラグインの確認（Kuromoji） bin/elasticsearch-plugin install analysis-kuromoji 4. MeCab本体のインストール（macOS向け） brew install mecab mecab-ipadic 5. OpenAI APIキーの設定 export OPENAI_API_KEY="sk-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx" Python環境とテキスト設定 import os import sys import platform import re from dotenv import load_dotenv # Import the working elasticsearch connection utility from elastic_conection import es, test_connection # Japanese text analysis libraries import MeCab from janome.tokenizer import Tokenizer from sudachipy import tokenizer as sudachi_tokenizer from sudachipy import dictionary as sudachi_dictionary # OpenAI for LLM comparison from openai import OpenAI # Environment and target text setup print("Python環境情報") print("="*30) print(f"Python Version: {sys.version.split()[0]}") print(f"Platform: {platform.platform()}") print(f"Architecture: {platform.machine()}") # Check if in virtual environment if hasattr(sys, 'real_prefix') or (hasattr(sys, 'base_prefix') and sys.base_prefix != sys.prefix): print("仮想環境で実行中") else: print("仮想環境ではありません") print(f"実行環境: {sys.executable}") # Define the target text for analysis TARGET_TEXT = """ロキソニン錠の説明書ですね。ロキソニンは、解熱鎮痛作用のある非ステロイド性抗炎症薬（NSAIDs）で、 痛みや発熱、炎症を抑える効果があります。具体的には、関節リウマチ、変形性関節症、腰痛症、肩こり、 歯痛、手術後や外傷後の炎症や痛み、風邪による熱や痛みなどに用いられます。""" print(f"\n分析対象テキスト: {TARGET_TEXT}") print(f"文字数: {len(TARGET_TEXT)}") print() Python環境情報 ============================== Python Version: 3.13.3 Platform: macOS-15.5-arm64-arm-64bit-Mach-O Architecture: arm64 仮想環境で実行中 実行環境: /Users/*****/es-analyzer-project/.venv/bin/python 分析対象テキスト: ロキソニン錠の説明書ですね。ロキソニンは、解熱鎮痛作用のある非ステロイド性抗炎症薬（NSAIDs）で、 痛みや発熱、炎症を抑える効果があります。具体的には、関節リウマチ、変形性関節症、腰痛症、肩こり、 歯痛、手術後や外傷後の炎症や痛み、風邪による熱や痛みなどに用いられます。 文字数: 137 トークン正規化・クリーニング関数 Kuromoji を基準（ベースライン）として使用 し、他のアナライザーの結果をKuromojiレベルまでクリーニングして比較します。 比較戦略 1. Kuromoji = ベースライン クリーニングなし : Kuromojiの生出力をそのまま使用 理由 : Elasticsearchに最適化済み、自然にストップワード除去済み 役割 : 他のアナライザーの目標レベルとして機能 2. 他のアナライザー = Kuromojiレベルまでクリーニング MeCab, SudachiPy, Janome, OpenAI : クリーニング関数を適用 目標 : Kuromojiと同等の品質レベルに調整 比較 : クリーニング後にKuromojiとの類似度を測定 クリーニング処理内容（Kuromoji以外） 1. 助詞・助動詞の除去 : 「は」「を」「に」「が」など機能語の削除 2. 句読点・記号の除去 : 「、」「。」「（」「）」などの除去 3. ストップワードの除去 : 検索で意味の薄い語の削除 4. 空白・数字の除去 : 純粋な数字や空白文字の除去 期待される効果 公平な比較 : 全アナライザーが同じ品質レベルで比較される 実用性評価 : 検索エンジンでの実際の使用場面を想定 最適化効果 : 各アナライザーのクリーニング後の性能向上を確認 Kuromoji優位性 : Elasticsearchプラグインとしての最適化効果を確認 def clean_tokens_like_kuromoji(tokens): """ Clean tokens to match Kuromoji's behavior by removing stop words and punctuation. Args: tokens (list): List of token strings Returns: list: Cleaned tokens with stop words and punctuation removed """ # Japanese stop words and particles commonly filtered out stop_words = { 'は', 'の', 'を', 'に', 'が', 'で', 'と', 'から', 'まで', 'より', 'へ', 'や', 'か', 'も', 'て', 'た', 'だ', 'である', 'です', 'ます', 'した', 'する', 'ある', 'いる', 'なる', 'この', 'その', 'あの', 'どの', 'これ', 'それ', 'あれ', 'どれ', 'ここ', 'そこ', 'あそこ', 'どこ', 'こう', 'そう', 'ああ', 'どう', 'という', 'といった', 'による', 'において', 'について', 'に関して', 'に対して', 'に関する', 'について', 'さん', 'ちゃん', 'くん', 'さま', 'さあ', 'まあ', 'ああ', 'いや', 'はい', 'いいえ', 'うん', 'ううん', 'えー', 'あー', 'うー', 'おー' } # Punctuation and symbols to remove punctuation_patterns = [ r'^[、。！？.,!?;:()（）\[\]「」『』【】〈〉《》〔〕…‥・]+$', # Pure punctuation r'^[ー\-~〜]+$', # Long vowel marks and dashes r'^[　\s]+$', # Whitespace (including full-width) r'^\d+$', # Pure numbers r'^[a-zA-Z]+$', # Pure alphabet r'^[０-９]+$', # Full-width numbers r'^[ａ-ｚＡ-Ｚ]+$' # Full-width alphabet ] cleaned = [] for token in tokens: if not token or not token.strip(): continue # Remove stop words if token in stop_words: continue # Remove punctuation and unwanted patterns is_punctuation = False for pattern in punctuation_patterns: if re.match(pattern, token): is_punctuation = True break if not is_punctuation: cleaned.append(token) return cleaned print("Token cleaning function defined") トークナイザー初期化・接続確認 各トークナイザーを初期化し、動作確認を行います。 初期化対象 : 1. Elasticsearch + Kuromoji ローカルElasticsearchサーバー（localhost:9200）への接続 Kuromojiアナライザーの利用可能性確認 2. MeCab Homebrew環境のIPA辞書パス設定 分かち書きモード（-O wakati）での初期化 3. SudachiPy 標準辞書の読み込み A/B/Cモード対応トークナイザーオブジェクト作成 4. Janome 純Python実装のトークナイザー初期化 依存関係なしの簡単セットアップ 5. OpenAI GPT-4o 環境変数からAPIキー取得 GPT-4モデルへの接続確認 注意 : 各ツールが正常に初期化されない場合、エラーメッセージが表示されます。 # === システム接続確認とトークナイザー初期化 === print("=== システム接続確認 ===") # Elasticsearch接続と初期化 print("Elasticsearchに接続中...") try: # elastic_conection.pyからESクライアントをインポート from elastic_conection import es, test_connection # 接続テスト if test_connection(): es_available = True print("Elasticsearch接続成功") else: es_available = False print("Elasticsearch接続失敗") print("解決方法: Elasticsearchサーバーを起動してください") print(" brew services start elasticsearch") except Exception as e: es_available = False print(f"Elasticsearch接続失敗: {e}") print("解決方法: Elasticsearchサーバーを起動してください") print(" brew services start elasticsearch") # 各トークナイザーの初期化 print("\nトークナイザーを初期化中...") # MeCab初期化 (Homebrew環境対応) tagger = None try: import MeCab # Homebrew環境用の設定リスト（正しいmecabrcパスを含む） configs_to_try = [ "-r /opt/homebrew/etc/mecabrc -Owakati", # Homebrew mecabrc + wakati mode "-r /opt/homebrew/etc/mecabrc", # Homebrew mecabrc only "-Owakati", # wakati mode only "", # デフォルト設定 "-d /opt/homebrew/lib/mecab/dic/ipadic", # ipadic辞書パス (Homebrew) "-d /usr/local/lib/mecab/dic/ipadic", # ipadic辞書パス (従来のパス) ] for config in configs_to_try: try: print(f" MeCab設定を試行中: '{config if config else 'デフォルト'}'") tagger = MeCab.Tagger(config) # テスト実行して動作確認 test_result = tagger.parse("テスト") if test_result and len(test_result.strip()) > 0: mecab_config = config if config else "デフォルト設定" print(f"MeCab初期化成功 (設定: {mecab_config})") print(f" テスト結果: {test_result.strip()}") break except Exception as e: print(f" 設定失敗: {e}") continue if not tagger: print("MeCab初期化失敗: MeCab could not be initialized with any configuration") print("解決方法: brew install mecab mecab-ipadic") except ImportError: print("MeCab初期化失敗: MeCabがインストールされていません") print("解決方法: brew install mecab mecab-ipadic") # SudachiPy初期化 tokenizer_obj = None try: from sudachipy import tokenizer from sudachipy import dictionary tokenizer_obj = dictionary.Dictionary().create() print("SudachiPy初期化成功") except Exception as e: print(f"SudachiPy初期化失敗: {e}") # Janome初期化 janome_tokenizer = None try: from janome.tokenizer import Tokenizer janome_tokenizer = Tokenizer() print("Janome初期化成功") except Exception as e: print(f"Janome初期化失敗: {e}") # OpenAI API初期化 openai_client = None try: import openai from dotenv import load_dotenv import os load_dotenv() api_key = os.getenv("OPENAI_API_KEY") if api_key: openai_client = openai.OpenAI(api_key=api_key) print("OpenAI API初期化成功") else: print("OpenAI API初期化失敗: APIキーが設定されていません") print("解決方法: .envファイルにOPENAI_API_KEYを設定してください") except Exception as e: print(f"OpenAI API初期化失敗: {e}") # 初期化サマリー print("\n初期化サマリー:") print(f" Elasticsearch: {'OK' if es_available else 'NG'}") print(f" MeCab: {'OK' if tagger else 'NG'}") print(f" SudachiPy: {'OK' if tokenizer_obj else 'NG'}") print(f" Janome: {'OK' if janome_tokenizer else 'NG'}") print(f" OpenAI: {'OK' if openai_client else 'NG'}") トークン化関数の定義（共通フォーマット出力） tokenize_with_kuromoji(text) tokenize_with_mecab(text) tokenize_with_sudachi(text, mode) tokenize_with_janome(text) tokenize_with_openai(text) すべての関数でエラーハンドリングを実装し、失敗時は空リストを返します。 def tokenize_with_kuromoji(text): """Tokenize text using Elasticsearch Kuromoji analyzer""" if not es_available: print("Kuromoji tokenization skipped: Elasticsearch not available") return [] try: response = es.indices.analyze( body={ "analyzer": "kuromoji", "text": text } ) return [token['token'] for token in response['tokens']] except Exception as e: print(f"Kuromoji tokenization error: {e}") return [] def tokenize_with_mecab(text): """Tokenize text using MeCab""" if not tagger: print("MeCab tokenization skipped: MeCab not available") return [] try: result = tagger.parse(text).strip().split() return [token for token in result if token] except Exception as e: print(f"MeCab tokenization error: {e}") return [] def tokenize_with_sudachi(text, mode='C'): """Tokenize text using SudachiPy with specified mode (A, B, or C)""" if not tokenizer_obj: print("SudachiPy tokenization skipped: SudachiPy not available") return [] try: mode_map = {'A': sudachi_tokenizer.Tokenizer.SplitMode.A, 'B': sudachi_tokenizer.Tokenizer.SplitMode.B, 'C': sudachi_tokenizer.Tokenizer.SplitMode.C} tokens = tokenizer_obj.tokenize(text, mode_map[mode]) return [token.surface() for token in tokens] except Exception as e: print(f"SudachiPy tokenization error: {e}") return [] def tokenize_with_janome(text): """Tokenize text using Janome""" if not janome_tokenizer: print("Janome tokenization skipped: Janome not available") return [] try: tokens = janome_tokenizer.tokenize(text, wakati=True) return list(tokens) except Exception as e: print(f"Janome tokenization error: {e}") return [] def tokenize_with_openai(text): """Tokenize text using OpenAI GPT-4""" if not openai_client: print("OpenAI tokenization skipped: OpenAI client not available") return [] try: prompt = f""" Please tokenize the following Japanese text into meaningful segments. Return only a comma-separated list of tokens, no explanations. Text: {text} Tokens:""" response = openai_client.chat.completions.create( model="gpt-4", messages=[{"role": "user", "content": prompt}], max_tokens=200, temperature=0 ) result = response.choices[0].message.content.strip() tokens = [token.strip() for token in result.split(',')] return [token for token in tokens if token] except Exception as e: print(f"OpenAI tokenization error: {e}") return [] print("All tokenization functions defined (with availability checks)") 包括的トークナイザー比較分析 def compare_all_tokenizers(text): """Compare all tokenizers on the given text - using Kuromoji as baseline (no cleaning)""" print(f"分析対象テキスト: {text}") print("=" * 80) results = {} # 1. Kuromoji (Elasticsearch) - BASELINE (no cleaning applied) print("\n1. Kuromoji (Elasticsearch) - ベースライン") kuromoji_tokens = tokenize_with_kuromoji(text) results['kuromoji'] = { 'raw': kuromoji_tokens, 'cleaned': kuromoji_tokens # No cleaning - use as baseline } print(f"Raw/Baseline ({len(kuromoji_tokens)}): {kuromoji_tokens}") print("Kuromojiはベースラインとして使用（クリーニングなし）") # 2. SudachiPy (all modes) - cleaned to match Kuromoji behavior for mode in ['A', 'B', 'C']: print(f"\n2. SudachiPy Mode {mode} - Kuromojiベース調整済み") sudachi_tokens = tokenize_with_sudachi(text, mode) sudachi_cleaned = clean_tokens_like_kuromoji(sudachi_tokens) results[f'sudachi_{mode}'] = { 'raw': sudachi_tokens, 'cleaned': sudachi_cleaned } print(f"Raw ({len(sudachi_tokens)}): {sudachi_tokens}") print(f"Cleaned ({len(sudachi_cleaned)}): {sudachi_cleaned}") # 3. MeCab - cleaned to match Kuromoji behavior print(f"\n3. MeCab - Kuromojiベース調整済み") mecab_tokens = tokenize_with_mecab(text) mecab_cleaned = clean_tokens_like_kuromoji(mecab_tokens) results['mecab'] = { 'raw': mecab_tokens, 'cleaned': mecab_cleaned } print(f"Raw ({len(mecab_tokens)}): {mecab_tokens}") print(f"Cleaned ({len(mecab_cleaned)}): {mecab_cleaned}") # 4. Janome - cleaned to match Kuromoji behavior print(f"\n4. Janome - Kuromojiベース調整済み") janome_tokens = tokenize_with_janome(text) janome_cleaned = clean_tokens_like_kuromoji(janome_tokens) results['janome'] = { 'raw': janome_tokens, 'cleaned': janome_cleaned } print(f"Raw ({len(janome_tokens)}): {janome_tokens}") print(f"Cleaned ({len(janome_cleaned)}): {janome_cleaned}") # 5. OpenAI GPT-4 - cleaned to match Kuromoji behavior if openai_client: print(f"\n5. OpenAI GPT-4 - Kuromojiベース調整済み") openai_tokens = tokenize_with_openai(text) openai_cleaned = clean_tokens_like_kuromoji(openai_tokens) results['openai'] = { 'raw': openai_tokens, 'cleaned': openai_cleaned } print(f"Raw ({len(openai_tokens)}): {openai_tokens}") print(f"Cleaned ({len(openai_cleaned)}): {openai_cleaned}") else: print(f"\n5. OpenAI GPT-4 (スキップ - API key not available)") # Comparison summary with Kuromoji as baseline print(f"\nKuromojiベースライン比較:") kuromoji_baseline = set(results['kuromoji']['cleaned']) for name, data in results.items(): if name != 'kuromoji': cleaned_tokens = set(data['cleaned']) overlap = len(kuromoji_baseline & cleaned_tokens) total_unique = len(kuromoji_baseline | cleaned_tokens) similarity = (overlap / total_unique * 100) if total_unique > 0 else 0 print(f" {name:<12}: {similarity:.1f}% similarity to Kuromoji baseline") return results # Run the comparison analysis_results = compare_all_tokenizers(TARGET_TEXT) 📊 Kuromoji（ベースライン）出力 トークン数：42 特徴：分かち書きが細かく、Elasticsearchでのインデックスに最適 📊 Sudachi A/B/C、MeCab、Janome、GPT-4 出力 Sudachiモードごとに粒度が変化 GPT-4oは語彙的まとまり重視で分割が異なる MeCab・Janomeは細かく分かれ、類似度が高い 1. Kuromoji (Elasticsearch) - ベースライン Raw/Baseline (42): ['ロキソニン', '錠', '説明', '書', 'ロキソニン', '解熱', '鎮痛', '作用', '非', 'ステロイド', '性', '抗', '炎症', '薬', 'nsaids', '痛み', '発熱', '炎症', '抑える', '効果', '具体', '的', '関節', 'リウマチ', '変形', '性', '関節', '症', '腰痛', '症', '肩こり', '歯痛', '手術', '後', '外傷', '後', '炎症', '痛む', '風邪', '熱', '痛み', '用いる'] Kuromojiはベースラインとして使用（クリーニングなし） 2. SudachiPy Mode A Raw (86): ['ロキソニン', '錠', 'の', '説明', '書', 'です', 'ね', '。', 'ロキソニン', 'は', '、', '解熱', '鎮痛', '作用', 'の', 'ある', '非', 'ステロイド', '性', '抗', '炎症', '薬', '（', 'NSAIDs', '）', 'で', '、', '\n', '痛', 'み', 'や', '発熱', '、', '炎症', 'を', '抑える', '効果', 'が', 'あり', 'ます', '。', '具体', '的', 'に', 'は', '、', '関節', 'リウマチ', '、', '変形', '性', '関節', '症', '、', '腰痛', '症', '、', '肩こり', '、', '\n', '歯痛', '、', '手術', '後', 'や', '外傷', '後', 'の', '炎症', 'や', '痛', 'み', '、', '風邪', 'に', 'よる', '熱', 'や', '痛', 'み', 'など', 'に', '用い', 'られ', 'ます', '。'] Cleaned (49): ['ロキソニン', '錠', '説明', '書', 'ね', 'ロキソニン', '解熱', '鎮痛', '作用', '非', 'ステロイド', '性', '抗', '炎症', '薬', '痛', 'み', '発熱', '炎症', '抑える', '効果', 'あり', '具体', '的', '関節', 'リウマチ', '変形', '性', '関節', '症', '腰痛', '症', '肩こり', '歯痛', '手術', '後', '外傷', '後', '炎症', '痛', 'み', '風邪', 'よる', '熱', '痛', 'み', 'など', '用い', 'られ'] 2. SudachiPy Mode B Raw (78): ['ロキソニン', '錠', 'の', '説明書', 'です', 'ね', '。', 'ロキソニン', 'は', '、', '解熱', '鎮痛', '作用', 'の', 'ある', '非', 'ステロイド', '性', '抗', '炎症', '薬', '（', 'NSAIDs', '）', 'で', '、', '\n', '痛み', 'や', '発熱', '、', '炎症', 'を', '抑える', '効果', 'が', 'あり', 'ます', '。', '具体的', 'に', 'は', '、', '関節', 'リウマチ', '、', '変形性', '関節症', '、', '腰痛症', '、', '肩こり', '、', '\n', '歯痛', '、', '手術', '後', 'や', '外傷', '後', 'の', '炎症', 'や', '痛み', '、', '風邪', 'に', 'よる', '熱', 'や', '痛み', 'など', 'に', '用い', 'られ', 'ます', '。'] Cleaned (41): ['ロキソニン', '錠', '説明書', 'ね', 'ロキソニン', '解熱', '鎮痛', '作用', '非', 'ステロイド', '性', '抗', '炎症', '薬', '痛み', '発熱', '炎症', '抑える', '効果', 'あり', '具体的', '関節', 'リウマチ', '変形性', '関節症', '腰痛症', '肩こり', '歯痛', '手術', '後', '外傷', '後', '炎症', '痛み', '風邪', 'よる', '熱', '痛み', 'など', '用い', 'られ'] 2. SudachiPy Mode C Raw (78): ['ロキソニン', '錠', 'の', '説明書', 'です', 'ね', '。', 'ロキソニン', 'は', '、', '解熱', '鎮痛', '作用', 'の', 'ある', '非', 'ステロイド', '性', '抗', '炎症', '薬', '（', 'NSAIDs', '）', 'で', '、', '\n', '痛み', 'や', '発熱', '、', '炎症', 'を', '抑える', '効果', 'が', 'あり', 'ます', '。', '具体的', 'に', 'は', '、', '関節', 'リウマチ', '、', '変形性', '関節症', '、', '腰痛症', '、', '肩こり', '、', '\n', '歯痛', '、', '手術', '後', 'や', '外傷', '後', 'の', '炎症', 'や', '痛み', '、', '風邪', 'に', 'よる', '熱', 'や', '痛み', 'など', 'に', '用い', 'られ', 'ます', '。'] Cleaned (41): ['ロキソニン', '錠', '説明書', 'ね', 'ロキソニン', '解熱', '鎮痛', '作用', '非', 'ステロイド', '性', '抗', '炎症', '薬', '痛み', '発熱', '炎症', '抑える', '効果', 'あり', '具体的', '関節', 'リウマチ', '変形性', '関節症', '腰痛症', '肩こり', '歯痛', '手術', '後', '外傷', '後', '炎症', '痛み', '風邪', 'よる', '熱', '痛み', 'など', '用い', 'られ'] 3. MeCab Raw (80): ['ロキソニン', '錠', 'の', '説明', '書', 'です', 'ね', '。', 'ロキソニン', 'は', '、', '解熱', '鎮痛', '作用', 'の', 'ある', '非', 'ステロイド', '性', '抗', '炎症', '薬', '（', 'NSAIDs', '）', 'で', '、', '痛み', 'や', '発熱', '、', '炎症', 'を', '抑える', '効果', 'が', 'あり', 'ます', '。', '具体', '的', 'に', 'は', '、', '関節', 'リウマチ', '、', '変形', '性', '関節', '症', '、', '腰痛', '症', '、', '肩こり', '、', '歯痛', '、', '手術', '後', 'や', '外傷', '後', 'の', '炎症', 'や', '痛み', '、', '風邪', 'による', '熱', 'や', '痛み', 'など', 'に', '用い', 'られ', 'ます', '。'] Cleaned (45): ['ロキソニン', '錠', '説明', '書', 'ね', 'ロキソニン', '解熱', '鎮痛', '作用', '非', 'ステロイド', '性', '抗', '炎症', '薬', '痛み', '発熱', '炎症', '抑える', '効果', 'あり', '具体', '的', '関節', 'リウマチ', '変形', '性', '関節', '症', '腰痛', '症', '肩こり', '歯痛', '手術', '後', '外傷', '後', '炎症', '痛み', '風邪', '熱', '痛み', 'など', '用い', 'られ'] 4. Janome Raw (82): ['ロキソニン', '錠', 'の', '説明', '書', 'です', 'ね', '。', 'ロキソニン', 'は', '、', '解熱', '鎮痛', '作用', 'の', 'ある', '非', 'ステロイド', '性', '抗', '炎症', '薬', '（', 'NSAIDs', '）', 'で', '、', '\n', '痛み', 'や', '発熱', '、', '炎症', 'を', '抑える', '効果', 'が', 'あり', 'ます', '。', '具体', '的', 'に', 'は', '、', '関節', 'リウマチ', '、', '変形', '性', '関節', '症', '、', '腰痛', '症', '、', '肩こり', '、', '\n', '歯痛', '、', '手術', '後', 'や', '外傷', '後', 'の', '炎症', 'や', '痛み', '、', '風邪', 'による', '熱', 'や', '痛み', 'など', 'に', '用い', 'られ', 'ます', '。'] Cleaned (45): ['ロキソニン', '錠', '説明', '書', 'ね', 'ロキソニン', '解熱', '鎮痛', '作用', '非', 'ステロイド', '性', '抗', '炎症', '薬', '痛み', '発熱', '炎症', '抑える', '効果', 'あり', '具体', '的', '関節', 'リウマチ', '変形', '性', '関節', '症', '腰痛', '症', '肩こり', '歯痛', '手術', '後', '外傷', '後', '炎症', '痛み', '風邪', '熱', '痛み', 'など', '用い', 'られ'] 5. OpenAI GPT-4o Raw (40): ['ロキソニン錠', 'の', '説明書', 'です', 'ね', '。', 'ロキソニン', 'は', '、', '解熱鎮痛作用', 'の', 'ある', '非ステロイド性抗炎症薬', '（', 'NSAIDs', '）', 'で', '、', '痛み', 'や', '発熱', '、', '炎症', 'を', '抑える', '効果', 'が', 'あります', '。', '具体的', 'に', 'は', '、', '関節リウマチ', '、', '変形性関節症', '、', '腰痛症', '、', '肩こり'] Cleaned (17): ['ロキソニン錠', '説明書', 'ね', 'ロキソニン', '解熱鎮痛作用', '非ステロイド性抗炎症薬', '痛み', '発熱', '炎症', '抑える', '効果', 'あります', '具体的', '関節リウマチ', '変形性関節症', '腰痛症', '肩こり'] 分析結果サマリー・統計表 トークン化結果を定量的に分析し、各アナライザーの特性を明確にします。 サマリーテーブル内容 : 1. トークン数比較表 Raw Tokens : 各アナライザーの生トークン数 Cleaned Tokens : クリーニング後のトークン数 Effectiveness : クリーニング効果率（ノイズ除去率） 2. ユニークトークン分析 各アナライザー固有のトークン : 他では検出されない独自トークン 全アナライザー共通トークン : すべてで一致する基本トークン トークン多様性 : 全体での語彙カバレッジ 分析指標 : トークン総数 : 各手法の分割粒度の違い 共通度 : アナライザー間の一致率 独自性 : 各手法の特徴的な分割パターン 活用方法 : 検索システム : 共通トークンは検索精度向上に寄与 NLP処理 : 用途に応じた最適アナライザー選択 品質評価 : トークン化の一貫性・信頼性評価 Tokenization Results Summary - Kuromoji Baseline ========================================================================================== Tokenizer Raw Tokens Final Tokens vs Kuromoji Note ------------------------------------------------------------------------------------------ kuromoji 42 42 100.0% ベースライン sudachi_A 86 49 71.4% クリーニング済み sudachi_B 78 41 53.3% クリーニング済み sudachi_C 78 41 53.3% クリーニング済み mecab 80 45 79.5% クリーニング済み janome 82 45 79.5% クリーニング済み openai 40 17 15.9% クリーニング済み 上の表の読み解き方； Raw Tokens (生トークン数) アナライザーがテキストを最初に分割した直後のトークン（単語）の総数です。この数値が大きいほど、より細かく単語を分割していることを示します。 Final Tokens (最終トークン数) 「生トークン」から助詞（「は」「が」など）、句読点、記号といった検索ノイズになりやすい不要なトークンを取り除いた（クリーニングした）後の数です。 このクリーニング処理により、各アナライザーを公平な土俵で比較できるようになります。 vs Kuromoji (Kuromojiとの類似度) クリーニング後のトークンセットが、基準であるKuromojiのトークンセットとどれだけ似ているかを示す割合（Jaccard係数）です。 計算式 : (両者に共通するトークン数) ÷ (どちらか一方にでも存在するユニークなトークン総数) このパーセンテージが高いほど、そのアナライザーの分割結果がKuromojiと似ていることを意味します。例えば、MeCabとJanomeはクリーニング後に80%の類似度となり、Kuromojiと非常に近い結果を出していることがわかります。 🔍 Unique Tokens Analysis (Cleaned Results vs Kuromoji Baseline) ====================================================================== sudachi_A: ['あり', 'など', 'ね', 'み', 'よる', 'られ', '用い', '痛'] sudachi_B: ['あり', 'など', 'ね', 'よる', 'られ', '具体的', '変形性', '用い', '腰痛症', '説明書', '関節症'] sudachi_C: ['あり', 'など', 'ね', 'よる', 'られ', '具体的', '変形性', '用い', '腰痛症', '説明書', '関節症'] mecab: ['あり', 'など', 'ね', 'られ', '用い'] janome: ['あり', 'など', 'ね', 'られ', '用い'] openai: ['あります', 'ね', 'ロキソニン錠', '具体的', '変形性関節症', '腰痛症', '解熱鎮痛作用', '説明書', '関節リウマチ', '非ステロイド性抗炎症薬'] Kuromoji unique tokens (not found in cleaned versions of others): kuromoji: ['nsaids', '用いる', '痛む'] Common tokens across all tokenizers (after cleaning): ['ロキソニン', '効果', '抑える', '炎症', '発熱', '肩こり'] 📊 統計サマリー: 📊 Kuromojiベースライン総トークン数: 34 📊 全アナライザー共通トークン数: 6 📊 共通度: 17.6% 上記は「各アナライザーのクリーニング後トークン」から「Kuromojiのトークン」を引いた残りのリストです。つまり、 Kuromojiにはないが、そのアナライザーだけが生成したユニークなトークン です。各ツールの辞書や分割ルールの違いが見てとれます。 Kuromojiだけが生成したトークン の後に、クリーニング後に すべてのアナライザーが共通して生成したトークン です。これらは、どのツールを使っても分割結果が変わらない、文章の核となる重要な単語と言えます。 考察 Kuromoji / MeCab / Janome 「専門職」→「専門」「職」、「看護師」→「看護」「師」のように、単語を細かく分割します。 これにより検索ヒット率が向上し、部分一致検索や強調表示に適しています。 Sudachi 「専門職」や「看護師」などの複合語を1トークンとして保持します。 意味のまとまりを重視する分析に向いており、モード切り替え（A/B/C）で粒度を調整できます。 Cモード : 「より良い検索体験を提供したい」が1語扱いになるため、特定の複合語での検索には不向きな場合があります。 Bモード : 実用面でバランスの取れた粒度を提供します。 LLM（GPT-4o） 文脈理解に基づいた分かち書きが可能です。 「介護福祉士」や「認知症」など、語彙として自然なまとまりで出力されます。 トークンの一貫性がないため、Elasticsearchのインデックス用途には不向きですが、意味理解や質問応答に最適です。 まとめ 日本語検索において、どのアナライザーを使うかは「検索したい内容」と「求める粒度」によって変わります。 細かく一致させたいなら Kuromoji 検索文をそのまま一致させたいなら Sudachi Cモード バランス重視なら Sudachi Bモード The post 日本語アナライザーの比較：Kuromoji・Sudachi・MeCab・Janome・LLMの性能検証 first appeared on Elastic Portal .

目次 はじめに 対象読者 環境 Elasticsearch同梱モデル vs 外部モデル Elasticsearch同梱の Model を利用する場合 Elasticsearchの外部のEmbed Modelを利用する場合 比較表 Elasticsearchで密ベクトル生成に利用可能なサービス 準備 Cohere API Key の取得 Machine Learning インスタンス /_inference/text_embedding/用エンドポイントの作成 インデックスの作成 マッピングの作成 ドキュメントの登録 登録された密ベクトルの確認 密ベクトル検索 まとめ はじめに 今回は、Elasticsearchでの密ベクトル検索において、外部のEmbed Modelを利用する方法について解説します。 これまで、 ホワイトペーパー 「Elasticsearchを使った簡易RAGアプリケーションの作成」やブログ記事「 Elasticsearchでのベクトル検索の準備 」で密ベクトル検索をご紹介してきました。これらはElasticsearchが同梱している .multilingual-e5-small というEmbed Modelを利用していました。 本記事では、Elasticsearchの外部にあるEmbed Modelを使って密ベクトル検索を行う方法を詳しく説明します。 対象読者 Elasticsearchの初級者～中級者 環境 Elasticsearch 8.18以上、かつPlatinum License以上（筆者はElasticsearch 9.0.3 Enterprise Licenseで動作確認しました。） Cohere embed-multilingual-light-v3.0　（Elasticsearchの /_inference/text_embedding/ が対応しているEmbed Modelであれば動作します。筆者は左記のモデルで動作確認しました。） なお、本ブログで紹介する /_inference/text_embedding/ を使った密ベクトル生成は、Basic Licenseでは動作しません。Basic Licenseをご利用の場合は、ベクトル変換処理のプログラムを作成して、それらを呼び出すなどの対応が必要です。 また、本ブログではフィールドタイプに semantic_text を指定しています。semantic_text はv8.18でGAとなりました。 ※本記事では密ベクトル検索に焦点を当てるため、形態素解析や、形態素解析を利用したハイブリッド検索については省略します。 Elasticsearch同梱モデル vs 外部モデル Elasticsearchが同梱しているEmbed Modelを利用する方法と、外部のEmbed Modelを利用する方法を比較してみましょう。 Elasticsearch同梱の Model を利用する場合 Elasticsearch同梱の Embed Model を利用する場合のドキュメント登録時の概略図を以下に示します。 Elasticsearchの外部のEmbed Modelを利用する場合 Elasticsearch の外部の Embed Model を利用する場合のドキュメント登録時の概略図を以下に示します。 比較表 項目 Elasticsearch同梱のModelを利用 Elasticsearchの外部のModelを利用 手軽さ ○ Elasticsearchのみ契約すればよい × 別途、Embed Modelのサービス契約が必要 モデルの種類 × 少ない ○ 多い 費用 Elasticsearchの費用はかかるが、それ以外は不要。 外部のEmbed Modelの利用料は増えるが、Elasticsearchの費用を抑えられる。 頻繁に密ベクトル生成処理が呼ばれる場合、外部モデルを利用するよりも安くなる可能性あり。 密ベクトル生成処理が一定回数以下の場合、こちらが安くなる可能性あり。 外部のEmbed Modelの利用料金はモデルによって異なるため一概には言えませんが、モデルによっては低価格で利用できるものもあり、割安で導入できるケースもあります。 Elasticsearchで密ベクトル生成に利用可能なサービス Elasticsearchの/_inference/text_embedding/を使って文字列から密ベクトルを生成する際に利用可能なサービス名の一覧を以下に挙げます。 Elasticsearch公式ドキュメント の「Create … inference endpoint」のうち、task_type = text_embeddingが密ベクトル生成用のサービスに該当します。 サービス名の一覧 Alibaba Cloud AI Search Amazon Bedrock Azure AI Studio Azure OpenAI Cohere Elasticsearch Google AI Studio Google Vertex AI Hugging Face JinaAI Mistral OpenAI VoyageAI Watsonx inference integration ※V9用の公式ドキュメントでは1か所にまとめられていないようです。なお、V8用の公式ドキュメントでは、 こちら のようにリストアップされています。 ※/_inference/text_embedding/を使わず、独自にプログラムを作成して密ベクトル生成処理を組み込めば、上記以外のモデルも利用可能です。 今回は、この中から Cohere を使用します。モデルは embed-multilingual-light-v3.0（次元数:384）を使います。 準備 Cohere API Key の取得 Cohereにサインイン後、API Keyを取得してください。 （本ブログではCohereのembed-multilingual-light-v3.0を取り上げていますが、他のモデルでも問題ありません。） Machine Learning インスタンス Elasticsearchに同梱しているEmbed Model（.multilingual-e5-smallなど）を利用する場合はElasticsearchのMachine Learningインスタンスが必要ですが、外部のEmbed Modelを利用して密ベクトルを生成する場合は、 Machine Learningインスタンスは不要 です。 （取得したログに対して異常値検出を行うなど、ベクトル生成以外でMachine Learningの機能を利用する場合は Machine Learning インスタンスが必要となりますが、今回はMachine Learningの機能を使用しないため不要です。） /_inference/text_embedding/用エンドポイントの作成 https://www.elastic.co/docs/api/doc/elasticsearch/v9/operation/operation-inference-put-cohere を参考に、Cohere用のtext_embeddingエンドポイントを作成します。 以下のリクエストをKibanaのDevToolsのConsoleから発行します。 PUT /_inference/text_embedding/my_cohere_emb_light_v3_float { "service": "cohere", "service_settings": { "api_key": "取得した Cohere の Api Key", "model_id": "embed-multilingual-light-v3.0", "embedding_type": "float" } } service_settings内に記載するパラメーターは、サービスごとに異なります。 Cohereの場合は、embedding_typeなどを指定できます。今回は”float”とします。 ここで作成したinference_idは、後ほど参照します。 _inferenceのtext_embeddingエンドポイントの作成に成功すると、次のようなレスポンスが返ってきます。 { "inference_id": "my_cohere_emb_light_v3_float", "task_type": "text_embedding", "service": "cohere", "service_settings": { "similarity": "cosine", "dimensions": 384, "model_id": "embed-multilingual-light-v3.0", "rate_limit": { "requests_per_minute": 10000 }, "embedding_type": "float" }, "chunking_settings": { "strategy": "sentence", "max_chunk_size": 250, "sentence_overlap": 1 } } インデックスの作成 今回登録するドキュメントの内容は、ホワイトペーパーで使用した「柿之助」（ 青空文庫 より入手した「桃太郎」を改変したもの）とします。 下記のリクエストを Kibana の DevTools の Console から発行します。 PUT /kakinosuke_cohere_emb3_light_float/ { "settings": { "index": { "number_of_shards": 1, "number_of_replicas": 1, "refresh_interval": "3600s" } } } 今回は、形態素解析などの設定は省略しています。 マッピングの作成 下記のリクエストを Kibana の DevTools の Console から発行します。 PUT /kakinosuke_cohere_emb3_light_float/_mappings { "dynamic": false, "properties": { "chunk_no": { "type": "integer" }, "content": { "type": "text", "fields": { "text_embedding": { "type": "semantic_text", "inference_id": "my_cohere_emb_light_v3_float" } } } } } 今回は、形態素解析などの設定は省略しています。 作成するフィールドは3つです。 フィールド名 フィールドタイプ 説明 chunk_no integer チャンク番号 content text 内容（本文） content.text_embedding semantic_text 密ベクトル(384次元, float) content.text_embeddingにCohereで生成した密ベクトルを格納するよう、inference_idに先ほど作成した”my_cohere_emb_light_v3_float”を指定します。 ドキュメントの登録 実際の検索サービスであれば、登録処理を別途作成する必要がありますが、今回は事前に登録用のリクエストを用意し、それらを発行するだけとします。 登録する内容は、ホワイトペーパーで利用した「柿之助」（ 青空文庫 より入手した「桃太郎」を改変したもの）を利用します。 ただし、今回は説明を簡略化するため、オーバーラップなしで手動でチャンキングしています（繰り返しになりますが、あくまでサンプルアプリケーションのため簡略化しています）。 ドキュメントの登録リクエスト： ※Trial Licenseをご利用の場合、登録する時間間隔を空けるなど、利用レートが制限を超えないようにしてください。 POST /kakinosuke_cohere_emb3_light_float/_doc { "chunk_no": 1, "content": """むかし、むかし、あるところに、おじいさんとおばあさんがありました。まいにち、おじいさんは山へしば刈りに、おばあさんは川へ洗濯に行きました。" ある日、おばあさんが、川のそばで、せっせと洗濯をしていますと、川上から、大きな柿が一つ、 「ドンブラコッコ、スッコッコ。 ドンブラコッコ、スッコッコ。」 と流れて来ました。""" } POST /kakinosuke_cohere_emb3_light_float/_doc { "chunk_no": 2, "content": """「おやおや、これはみごとな柿だこと。おじいさんへのおみやげに、どれどれ、うちへ持って帰りましょう。」 おばあさんは、そう言いながら、腰をかがめて柿を取ろうとしましたが、遠くって手がとどきません。おばあさんはそこで、 「あっちの水は、かあらいぞ。 こっちの水は、ああまいぞ。 かあらい水は、よけて来い。 ああまい水に、よって来い。 と歌いながら、手をたたきました。すると柿はまた、 「ドンブラコッコ、スッコッコ。 ドンブラコッコ、スッコッコ。」 といいながら、おばあさんの前へ流れて来ました。""" } POST /kakinosuke_cohere_emb3_light_float/_doc { "chunk_no": 3, "content": """おばあさんはにこにこしながら、 「早くおじいさんと二人で分けて食べましょう。」 と言って、柿をひろい上げて、洗濯物といっしょにたらいの中に入れて、えっちら、おっちら、かかえておうちへ帰りました。""" } POST /kakinosuke_cohere_emb3_light_float/_doc { "chunk_no": 4, "content": """夕方になってやっと、おじいさんは山からしばを背負って帰って来ました。 「おばあさん、今帰ったよ。」 「おや、おじいさん、おかいんなさい。待っていましたよ。さあ、早くお上がんなさい。いいものを上げますから。」 「それはありがたいな。何だね、そのいいものというのは。」 こういいながら、おじいさんはわらじをぬいで、上に上がりました。""" } POST /kakinosuke_cohere_emb3_light_float/_doc { "chunk_no": 5, "content": """その間に、おばあさんは戸棚の中からさっきの柿を重そうにかかえて来て、 「ほら、ごらんなさいこの柿を。」 と言いました。 「ほほう、これはこれは。どこからこんなみごとな柿を買って来た。」 「いいえ、買って来たのではありません。今日川で拾って来たのですよ。」 「え、なに、川で拾って来た。それはいよいよめずらしい。」 こうおじいさんは言いながら、柿を両手にのせて、ためつ、すがめつ、ながめていますと、だしぬけに、柿はぽんと中から二つに割れて、 「おぎゃあ、おぎゃあ。」 と勇ましいうぶ声を上げながら、かわいらしい赤さんが元気よくとび出しました。""" } POST /kakinosuke_cohere_emb3_light_float/_doc { "chunk_no": 6, "content": """「おやおや、まあ。」 おじいさんも、おばあさんも、びっくりして、二人いっしょに声を立てました。 「まあまあ、わたしたちが、へいぜい、どうかして子供が一人ほしい、ほしいと言っていたものだから、きっと神さまがこの子をさずけて下さったにちがいない。」 おじいさんも、おばあさんも、うれしがって、こう言いました。 そこであわてておじいさんがお湯をわかすやら、おばあさんがむつきをそろえるやら、大さわぎをして、赤さんを抱き上げて、うぶ湯をつかわせました。するといきなり、 「うん。」 と言いながら、赤さんは抱いているおばあさんの手をはねのけました。 「おやおや、何という元気のいい子だろう。」 おじいさんとおばあさんは、こう言って顔を見合わせながら、「あッは、あッは。」とおもしろそうに笑いました。 そして柿の中から生まれた子だというので、この子に柿之助という名をつけました。""" } POST /kakinosuke_cohere_emb3_light_float/_doc { "chunk_no": 7, "content": """おじいさんとおばあさんは、それはそれはだいじにして柿之助を育てました。柿之助はだんだん成長するにつれて、あたりまえの子供にくらべては、ずっと体も大きいし、力がばかに強くって、すもうをとっても近所の村じゅうで、かなうものは一人もないくらいでしたが、そのくせ気だてはごくやさしくって、おじいさんとおばあさんによく孝行をしました。 柿之助は十五になりました。 もうそのじぶんには、日本の国中で、柿之助ほど強いものはないようになりました。柿之助はどこか外国へ出かけて、腕いっぱい、力だめしをしてみたくなりました。""" } POST /kakinosuke_cohere_emb3_light_float/_doc { "chunk_no": 8, "content": """するとそのころ、ほうぼう外国の島々をめぐって帰って来た人があって、いろいろめずらしい、ふしぎなお話をした末に、 「もう何年も何年も船をこいで行くと、遠い遠い海のはてに、悪霊島という所がある。悪い悪霊どもが、いかめしいくろがねのお城の中に住んで、ほうぼうの国からかすめ取った貴い宝物を守っている。」 と言いました。 柿之助はこの話をきくと、その悪霊島へ行ってみたくって、もう居ても立ってもいられなくなりました。そこでうちへ帰るとさっそく、おじいさんの前へ出て、 「どうぞ、わたくしにしばらくおひまを下さい。」 と言いました。""" } POST /kakinosuke_cohere_emb3_light_float/_doc { "chunk_no": 9, "content": """おじいさんはびっくりして、 「お前どこへ行くのだ。」 と聞きました。 「悪霊島へ悪霊せいばつに行こうと思います。」 と柿之助はこたえました。 「ほう、それはいさましいことだ。じゃあ行っておいで。」 とおじいさんは言いました。 「まあ、そんな遠方へ行くのでは、さぞおなかがおすきだろう。よしよし、おべんとうをこしらえて上げましょう。」 とおばあさんも言いました。""" } POST /kakinosuke_cohere_emb3_light_float/_doc { "chunk_no": 10, "content": """そこで、おじいさんとおばあさんは、お庭のまん中に、えんやら、えんやら、大きな臼を持ち出して、おじいさんがきねを取ると、おばあさんはこねどりをして、 「ぺんたらこっこ、ぺんたらこっこ。ぺんたらこっこ、ぺんたらこっこ。」 と、おべんとうのおむすびをつきはじめました。 おむすびがうまそうにでき上がると、柿之助のしたくもすっかりでき上がりました。 """ } POST /kakinosuke_cohere_emb3_light_float/_doc { "chunk_no": 11, "content": """柿之助はお侍の着るような陣羽織を着て、刀を腰にさして、おむすびの袋をぶら下げました。そして柿の絵のかいてある軍扇を手に持って、 「ではおとうさん、おかあさん、行ってまいります。」 と言って、ていねいに頭を下げました。 「じゃあ、りっぱに悪霊を退治してくるがいい。」 とおじいさんは言いました。 「気をつけて、けがをしないようにおしよ。」 とおばあさんも言いました。""" } POST /kakinosuke_cohere_emb3_light_float/_doc { "chunk_no": 12, "content": """「なに、大丈夫です、日本一のおむすびを持っているから。」と柿之助は言って、 「では、ごきげんよう。」 と元気な声をのこして、出ていきました。おじいさんとおばあさんは、門の外に立って、いつまでも、いつまでも見送っていました。 """ } POST /kakinosuke_cohere_emb3_light_float/_doc { "chunk_no": 13, "content": """柿之助はずんずん行きますと、大きな山の上に来ました。すると、草むらの中から、「ワン、ワン。」と声をかけながら、猫が一ぴきかけて来ました。 柿之助がふり返ると、猫はていねいに、おじぎをして、 「柿之助さん、柿之助さん、どちらへおいでになります。」 とたずねました。 「悪霊島へ、悪霊せいばつに行くのだ。」 「お腰に下げたものは、何でございます。」 「日本一のおむすびさ。」 「一つ下さい、お供しましょう。」 「よし、よし、やるから、ついて来い。」 猫はおむすびを一つもらって、柿之助のあとから、ついて行きました。""" } POST /kakinosuke_cohere_emb3_light_float/_doc { "chunk_no": 14, "content": """山を下りてしばらく行くと、こんどは森の中にはいりました。すると木の上から、「キャッ、キャッ。」とさけびながら、ゴリラが一ぴき、かけ下りて来ました。 柿之助がふり返ると、ゴリラはていねいに、おじぎをして、 「柿之助さん、柿之助さん、どちらへおいでになります。」 とたずねました。 「悪霊島へ悪霊せいばつに行くのだ。」 「お腰に下げたものは、何でございます。」 「日本一のおむすびさ。」 「一つ下さい、お供しましょう。」 「よし、よし、やるから、ついて来い。」 ゴリラもおむすびを一つもらって、あとからついて行きました。""" } POST /kakinosuke_cohere_emb3_light_float/_doc { "chunk_no": 15, "content": """山を下りて、森をぬけて、こんどはひろい野原へ出ました。すると空の上で、「ケン、ケン。」と鳴く声がして、鷹が一羽とんで来ました。 柿之助がふり返ると、鷹はていねいに、おじぎをして、 「柿之助さん、柿之助さん、どちらへおいでになります。」 とたずねました。 「悪霊島へ悪霊せいばつに行くのだ。」 「お腰に下げたものは、何でございます。」 「日本一のおむすびさ。」 「一つ下さい、お供しましょう。」 「よし、よし、やるから、ついて来い。」 鷹もおむすびを一つもらって、柿之助のあとからついて行きました。""" } POST /kakinosuke_cohere_emb3_light_float/_doc { "chunk_no": 16, "content": """猫と、ゴリラと、鷹と、これで三にんまで、いい家来ができたので、柿之助はいよいよ勇み立って、またずんずん進んで行きますと、やがてひろい海ばたに出ました。 　そこには、ちょうどいいぐあいに、船が一そうつないでありました。 　柿之助と、三にんの家来は、さっそく、この船に乗り込みました。 「わたくしは、漕ぎ手になりましょう。」 　こう言って、猫は船をこぎ出しました。 「わたくしは、かじ取りになりましょう。」 　こう言って、ゴリラがかじに座りました。 「わたくしは物見をつとめましょう。」 　こう言って、鷹がへさきに立ちました。 """ } POST /kakinosuke_cohere_emb3_light_float/_doc { "chunk_no": 17, "content": """うららかないいお天気で、まっ青な海の上には、波一つ立ちませんでした。稲妻が走るようだといおうか、矢を射るようだといおうか、目のまわるような速さで船は走って行きました。ほんの一時間も走ったと思うころ、へさきに立って向こうをながめていた鷹が、「あれ、あれ、島が。」とさけびながら、ぱたぱたと高い羽音をさせて、空にとび上がったと思うと、スウッとまっすぐに風を切って、飛んでいきました。 柿之助もすぐ鷹の立ったあとから向こうを見ますと、なるほど、遠い遠い海のはてに、ぼんやり雲のような薄ぐろいものが見えました。船の進むにしたがって、雲のように見えていたものが、だんだんはっきりと島の形になって、あらわれてきました。""" } POST /kakinosuke_cohere_emb3_light_float/_doc { "chunk_no": 18, "content": """「ああ、見える、見える、悪霊島が見える。」 柿之助がこういうと、猫も、ゴリラも、声をそろえて、「万歳、万歳。」とさけびました。 見る見る悪霊島が近くなって、もう硬い岩で畳んだ悪霊のお城が見えました。いかめしいくろがねの門の前に見はりをしている悪霊の兵隊のすがたも見えました。 そのお城のいちばん高い屋根の上に、鷹がとまって、こちらを見ていました。 こうして何年も、何年もこいで行かなければならないという悪霊島へ、ほんの目をつぶっている間に来たのです。""" } POST /kakinosuke_cohere_emb3_light_float/_doc { "chunk_no": 19, "content": """柿之助は、猫とゴリラをしたがえて、船からひらりと陸の上にとび上がりました。 見はりをしていた悪霊の兵隊は、その見なれないすがたを見ると、びっくりして、あわてて門の中に逃げ込んで、くろがねの門を固くしめてしまいました。その時猫は門の前に立って、 「日本の柿之助さんが、お前たちをせいばいにおいでになったのだぞ。あけろ、あけろ。」 とどなりながら、ドン、ドン、扉をたたきました。悪霊はその声を聞くと、ふるえ上がって、よけい一生懸命に、中から押さえていました。""" } POST /kakinosuke_cohere_emb3_light_float/_doc { "chunk_no": 20, "content": """すると鷹が屋根の上からとび下りてきて、門を押さえている悪霊どもの目をつつきまわりましたから、悪霊はへいこうして逃げ出しました。その間に、ゴリラがするすると高い岩壁をよじ登っていって、ぞうさなく門を中からあけました。 「わあッ。」とときの声を上げて、柿之助の主従が、いさましくお城の中に攻め込んでいきますと、悪霊の大将も大ぜいの家来を引き連れて、一人一人、太い鉄の棒をふりまわしながら、「おう、おう。」とさけんで、向かってきました。""" } POST /kakinosuke_cohere_emb3_light_float/_doc { "chunk_no": 21, "content": """けれども、体が大きいばっかりで、いくじのない悪霊どもは、さんざん鷹に目をつつかれた上に、こんどは猫に向こうずねをくいつかれたといっては、痛い、痛いと逃げまわり、ゴリラに顔を引っかかれたといっては、おいおい泣き出して、鉄の棒も何もほうり出して、降参してしまいました。 　おしまいまでがまんして、たたかっていた悪霊の大将も、とうとう柿之助に組みふせられてしまいました。柿之助は大きな悪霊の背中に、馬乗りにまたがって、 「どうだ、これでも降参しないか。」 　といって、ぎゅうぎゅう、ぎゅうぎゅう、押さえつけました。""" } POST /kakinosuke_cohere_emb3_light_float/_doc { "chunk_no": 22, "content": """悪霊の大将は、柿之助の大力で首をしめられて、もう苦しくってたまりませんから、大つぶの涙をぼろぼろこぼしながら、 「降参します、降参します。命だけはお助け下さい。その代わりに宝物をのこらずさし上げます。」 こう言って、ゆるしてもらいました。 悪霊の大将は約束のとおり、お城から、かくれみのに、かくれ笠、うちでの小づちに如意宝珠、そのほかさんごだの、たいまいだの、るりだの、世界でいちばん貴い宝物を山のように車に積んで出しました。""" } POST /kakinosuke_cohere_emb3_light_float/_doc { "chunk_no": 23, "content": """柿之助はたくさんの宝物をのこらず積んで、三にんの家来といっしょに、また船に乗りました。帰りは行きよりもまた一そう船の走るのが速くって、間もなく日本の国に着きました。 船が陸に着きますと、宝物をいっぱい積んだ車を、猫が先に立って引き出しました。鷹が綱を引いて、ゴリラがあとを押しました。 「えんやらさ、えんやらさ。」 三にんは重そうに、かけ声をかけかけ進んでいきました。 """ } POST /kakinosuke_cohere_emb3_light_float/_doc { "chunk_no": 24, "content": """うちではおじいさんと、おばあさんが、かわるがわる、 「もう柿之助が帰りそうなものだが。」 と言い言い、首をのばして待っていました。そこへ柿之助が三にんのりっぱな家来に、ぶんどりの宝物を引かせて、さもとくいらしい様子をして帰って来ましたので、おじいさんもおばあさんも、目も鼻もなくして喜びました。 「えらいぞ、えらいぞ、それこそ日本一だ。」 とおじいさんは言いました。 「まあ、まあ、けががなくって、何よりさ。」 とおばあさんは言いました。""" } POST /kakinosuke_cohere_emb3_light_float/_doc { "chunk_no": 25, "content": """柿之助は、その時猫とゴリラと鷹の方を向いてこう言いました。 「どうだ。悪霊せいばつはおもしろかったなあ。」 猫はワン、ワンとうれしそうにほえながら、前足で立ちました。 ゴリラはキャッ、キャッと笑いながら、白い歯をむき出しました。 鷹はケン、ケンと鳴きながら、くるくると宙返りをしました。 空は青々と晴れ上がって、お庭には桜の花が咲き乱れていました。""" } 最後に、_refreshを呼び出します。 POST /kakinosuke_cohere_emb3_light_float/_refresh 登録された密ベクトルの確認 下記のリクエストを Kibana の DevTools の Console から発行します。 GET /kakinosuke_cohere_emb3_light_float/_search { "size": 30, "query": { "match_all": {} }, "fields": [ "_inference_fields" ] } 以下のようなレスポンスが返却されます。 { "took": 15, ... "hits": { "hits": [ { "chunk_no": 4, "content": """夕方になってやっと、おじいさんは山からしばを背負って帰って来ました。... """, "_inference_fields": { "content.text_embedding": { "inference_id": "my_cohere_emb_light_v3_float", "model_settings": { "task_type": "text_embedding", "dimensions": 384, "similarity": "cosine", "element_type": "float" }, "chunks": { "content": [ { "start_offset": 0, "end_offset": 168, "embeddings": [ 0.095214844, -0.061676025, ... 0.05307007 ] } ] } } } }, ... ] } } float の密ベクトルが格納されていることがわかります。 ベクトル生成を明示的に行っていないにもかかわらず、ベクトルが計算され格納されているのは、/_inference/text_embeddingsのエンドポイントを作成し、それをインデックスのマッピングに指定したおかげです。 密ベクトル検索 準備ができたので、実際に密ベクトルを使った検索を行ってみましょう。 下記のリクエストを Kibana の DevTools の Console から発行します。 GET /kakinosuke_cohere_emb3_light_float/_search { "query": { "semantic": { "field": "content.text_embedding", "query": "川に流れてきた果物は何?" } } } レスポンス { "took": 103, ... "hits": [ { ... "_source": { "chunk_no": 1, "content": """むかし、むかし、あるところに、... 川上から、大きな柿が一つ、... """ } }, { ... "_source": { "chunk_no": 5, "content": """その間に、おばあさんは戸棚の中から... 「ほほう、これはこれは。どこからこんなみごとな柿を買って来た。」 「いいえ、買って来たのではありません。今日川で拾って来たのですよ。」 「え、なに、川で拾って来た。それはいよいよめずらしい。」 こうおじいさんは言いながら、柿を両手にのせて、... """ } }, { ... "_source": { "chunk_no": 2, "content": """「おやおや、これはみごとな柿だこと。... といいながら、おばあさんの前へ流れて来ました。""" } }, ... ] } } クエリー「川に流れてきた果物は何?」に近いドキュメントが返却されています。 検索時にもベクトル生成を明示していませんが、これも/_inference/text_embedding/のエンドポイントを作成した効果です。 なお、以前のベクトル検索では、 Elasticsearchでのベクトル検索 で紹介したように、次のようなやや複雑なクエリーを記述する必要がありました。 GET /momotaro_v3/_search { "knn": { "field": "text_embedding.predicted_value", "k": "10", "num_candidates": "100", "query_vector_builder": { "text_embedding": { "model_id": ".multilingual-e5-small_linux-x86_64", "model_text": "桃太郎が鬼が島へ向かった際の乗り物は" } } } } しかし、v8.18からは、 GET /インデックス名/_search { "query": { "semantic": { "field": "密ベクトルを格納しているフィールド名", "query": "検索したいテキスト" } } } といった簡素な構文で検索できるようになりました。詳細は こちら をご参照ください。 他の検索クエリも試してみます。 GET /kakinosuke_cohere_emb3_light_float/_search { "query": { "semantic": { "field": "content.text_embedding", "query": "柿之助の家来は誰?" } } } レスポンス： { "took": 173, ... "hits": { ... "hits": [ { ... "_source": { "chunk_no": 23, "content": """柿之助はたくさんの宝物をのこらず積んで、三にんの家来といっしょに... 猫が先に立って引き出しました。鷹が綱を引いて、ゴリラがあとを押しました。...""" } }, { ... "_source": { "chunk_no": 16, "content": """猫と、ゴリラと、鷹と、これで三にんまで、いい家来ができたので、柿之助はいよいよ...""" } }, ... ] } } 検索クエリ「柿之助の家来は誰?」に近いドキュメントが返却されています。 まとめ このように、Elasticsearchの外部のEmbed Modelを利用しても密ベクトル検索を行えることがご理解いただけたかと思います。 要件に合ったEmbed Modelを利用して環境を構築してみてください。 The post Elasticsearchでの外部のEmbed Modelを使った密ベクトル検索 first appeared on Elastic Portal .

目次 はじめに 対象者 前提条件 ドキュメントレベルセキュリティの概要 サンプルアプリ ソースコードの取得方法 インデックスの作成 インデックスへのマッピングの登録 ドキュメントの登録 APIキーの発行 ElasticsearchエンドポイントURLの取得 ビルド～コンテナとの接続 ビルド コンテナの起動 コンテナとの接続 サンプルプログラムの実行 ログイン画面の表示 ユーザーごとの動作確認 user1での動作確認 user2での動作確認 user3での動作確認 user4での動作確認 関連情報 Connector における Document Level Security Field Level Security まとめ はじめに これまで3回にわたって、インデックスごとのロールベースアクセス制御（RBAC） の設定方法について解説してきました。 Elasticsearchのインデックスに対するアクセス制御（概要 ） Elasticsearchのインデックスに対するアクセス制御（Kibana上での動作確認） Elasticsearchのインデックスに対するアクセス制御（API経由での動作確認） 今回は、ドキュメントレベルセキュリティ（Document Level Security: DLS） について説明します。 DLSを利用すると、以下のようなきめ細やかな権限設定が可能です。 ユーザーAはこのドキュメントを参照できる。 グループBはこのドキュメントを参照できる。 ユーザーCとグループDはこのドキュメントを参照できる。 対象者 Elasticsearch 中級者 前提条件 Elasticsearch Platinum License または Enterprise License （DLS機能は Basic License では利用できません。） Elasticsearch v9.0.3 （他のバージョンでも動作する可能性はありますが、筆者は Enterprise License v9.0.3 で動作確認済みです。） Docker 実行環境 （筆者は Rancher Desktop 1.19.3 で動作確認済みです。） Python 3.13 streamlit 1.42.2 streamlit-authenticator 0.4.2 ドキュメントレベルセキュリティの概要 ドキュメントレベルセキュリティの概要を図に示します。 まず、ドキュメントをインデックスに登録する際に、そのドキュメントを参照可能なユーザー名やグループ名も一緒に格納します。 次に、アクセスするユーザーのユーザー名とグループ名を記載した APIキー を発行します。 発行されたAPIキーを使用して検索を実行します。 APIキーが保持するユーザー名、グループ名で読み取り可能なドキュメントのみがヒットし、結果として返却されます。 この図だけでは分かりにくいかもしれないため、実際にサンプルアプリを動かして動作を確認してみましょう。 サンプルアプリ 今回紹介するサンプルアプリは、 GitHubリポジトリ で公開しています。ソースコードの詳細はそちらを参照してください。 ソースコードの取得方法 右記のURLにアクセスします。 : https://github.com/sios-elastic-tech/blogs [<> Code] から Download ZIP を選択してダウンロードします。 ダウンロードしたblogs-main.zipファイルを展開します。 2025-07-dlsフォルダに移動します。 cd 2025-07-dls 注記: 準備作業として必要なリクエストもこのフォルダに含まれています。 インデックスの作成 Document Level Security の動作確認を目的とした簡易的なインデックスのため、本文の形態素解析などは省略します。 以下のリクエストを Dev Tools の Console から発行してください。 PUT /dls_sample_202507 { "settings": { "index": { "number_of_shards": 1, "number_of_replicas": 1 }, "analysis": { "filter": { "en-stop-words-filter": { "type": "stop", "stopwords": "_english_" } }, "analyzer": { "iq_text_base": { "filter": [ "cjk_width", "lowercase", "asciifolding", "en-stop-words-filter" ], "tokenizer": "standard" } } } } } インデックスへのマッピングの登録 必要最低限のフィールドのみを生成します 本文用フィールド: content アクセス制御用フィールド: _allow_access_control 以下のリクエストを Dev Tools の Console から発行してください。 PUT /dls_sample_202507/_mapping { "properties": { "content": { "type": "text" }, "_allow_access_control": { "type": "text", "index_options": "freqs", "analyzer": "iq_text_base", "fields": { "enum": { "type": "keyword", "ignore_above": 2048 } } } } } ドキュメントの登録 検索対象となるドキュメントを登録します。その際、そのドキュメントを検索可能なユーザー名、グループ名も登録します。 読み取り権限は以下の表のようにしておきます。 ドキュメント 読み取り能なユーザー名、グループ名 doc1: … user1@example.com または group1 doc2: … user2@example.com または group2 doc3: … user1@example.com doc4: … user2@example.com doc5: … group1 doc6: … group2 doc7: … 全員 注記: doc7 には読み取り可能なユーザー、グループを明示していません。明示しない場合は、全員が読み取り可能とします。 以下のリクエストを Dev Tools の Console から発行してください。 POST /dls_sample_202507/_doc { "content": "doc1: This document can be read by user1 or group1.", "_allow_access_control": [ "user1@example.com", "group1" ] } POST /dls_sample_202507/_doc { "content": "doc2: This document can be read by user2 or group2.", "_allow_access_control": [ "user2@example.com", "group2" ] } POST /dls_sample_202507/_doc { "content": "doc3: This document can be read by user1.", "_allow_access_control": [ "user1@example.com" ] } POST /dls_sample_202507/_doc { "content": "doc4: This document can be read by user2.", "_allow_access_control": [ "user2@example.com" ] } POST /dls_sample_202507/_doc { "content": "doc5: This document can be read by group1.", "_allow_access_control": [ "group1" ] } POST /dls_sample_202507/_doc { "content": "doc6: This document can be read by group2.", "_allow_access_control": [ "group2" ] } POST /dls_sample_202507/_doc { "content": "doc7: This document can be read by everybody." } APIキーの発行 動作確認として、以下の4パターンのAPIキーを発行します。 APIキー名 ユーザー、グループ 有効期限 user1_api_key_20250702 user1@example.com, group1 1日 user2_api_key_20250702 user2@example.com, group2 1日 user3_api_key_20250702 user3@example.com, group1 1日 user4_api_key_20250702 user4@example.com, group2 1日 まず、user1用の以下のリクエストを Dev Tools の Console から発行してください。(*脚注1) 1 POST /_security/api_key { "name": "user1_api_key_20250702", "expiration": "1d", "role_descriptors": { "dls_sample_user1": { "cluster": ["monitor"], "index": [ { "names": [ "dls_sample_202507" ], "privileges": [ "read" ], "query": { "template": { "params": { "access_control": [ "user1@example.com", "group1" ] }, "source": """ { "bool": { "should": [ { "bool": { "must_not": { "exists": { "field": "_allow_access_control" } } } }, { "terms": { "_allow_access_control.enum": {{#toJson}}access_control{{/toJson}} } } ] } } """ } } } ] } } } ※このリクエストを見ると、なんとなく想像がつくと思いますが、超端的に言えば、検索クエリーの発行時に _allow_access_control フィールドを使って強制的にフィルタをかけるような動きになります。 ※_allow_access_control フィールドがないドキュメントは、全員読み取り可能とします。 成功すると、以下のようなレスポンスが返却されます。 { "id": "xxxxxxxxxxxxxxxxxx", "name": "user1_api_key_20250702", "expiration": xxxxxxxxxxxxxxx, "api_key": "xxxxxxxxxxxxxxxxxx", "encoded": "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx==" } このうち、encoded の値をコピーして、config.yaml の user1 の encoded_api_key に貼り付けます。 config.yaml: elasticsearch: endpoint: url_of_elasticsearch_endpoint cookie: expiry_days: 1 key: some_signature_key name: some_cookie_name credentials: usernames: user1: name: user1 password: secret_password encoded_api_key: dummy== user2: name: user2 password: secret_password encoded_api_key: dummy== user3: name: user3 password: secret_password encoded_api_key: dummy== user4: name: user4 password: secret_password encoded_api_key: dummy== 同様に、user2用のAPIキーを発行し、encoded の値を user2 の encoded_api_key の欄に貼り付けます。 POST /_security/api_key { "name": "user2_api_key_20250702", "expiration": "1d", "role_descriptors": { "dls_sample_user2": { "cluster": ["monitor"], "index": [ { "names": [ "dls_sample_202507" ], "privileges": [ "read" ], "query": { "template": { "params": { "access_control": [ "user2@example.com", "group2" ] }, "source": """ { "bool": { "should": [ { "bool": { "must_not": { "exists": { "field": "_allow_access_control" } } } }, { "terms": { "_allow_access_control.enum": {{#toJson}}access_control{{/toJson}} } } ] } } """ } } } ] } } } 同様にuser3用のAPIキーを発行し、user3 の encoded_api_key の欄に encoded の値を貼り付けます。 POST /_security/api_key { "name": "user3_api_key_20250702", "expiration": "1d", "role_descriptors": { "dls_sample_user3": { "cluster": ["monitor"], "index": [ { "names": [ "dls_sample_202507" ], "privileges": [ "read" ], "query": { "template": { "params": { "access_control": [ "user3@example.com", "group1" ] }, "source": """ { "bool": { "should": [ { "bool": { "must_not": { "exists": { "field": "_allow_access_control" } } } }, { "terms": { "_allow_access_control.enum": {{#toJson}}access_control{{/toJson}} } } ] } } """ } } } ] } } } 同様にuser4用のAPIキーを発行し、user4 の encoded_api_key の欄に encoded の値を貼り付けます。 POST /_security/api_key { "name": "user4_api_key_20250702", "expiration": "1d", "role_descriptors": { "dls_sample_user4": { "cluster": ["monitor"], "index": [ { "names": [ "dls_sample_202507" ], "privileges": [ "read" ], "query": { "template": { "params": { "access_control": [ "user4@example.com", "group2" ] }, "source": """ { "bool": { "should": [ { "bool": { "must_not": { "exists": { "field": "_allow_access_control" } } } }, { "terms": { "_allow_access_control.enum": {{#toJson}}access_control{{/toJson}} } } ] } } """ } } } ] } } } ※user1, user2, user3, user4 の Streamlit へのログインパスワードも config.yaml に記載してください。あくまでもサンプルアプリケーションですので、暗号化などは考慮していません。 ElasticsearchエンドポイントURLの取得 Elastic Kibana の Home 画面から Elasticsearch のエンドポイントURLを取得し、config.yamlファイルの endpoint に転記してください。 ビルド～コンテナとの接続 ビルド docker-compose.yml があるディレクトリに移動します。 cd app docker-compose.ymlがあるディレクトリで、以下のコマンドを実行します。 docker compose build コンテナの起動 docker compose up -d コンテナとの接続 docker exec -it dls_sample_202507 /bin/bash （dls_sample_202507はコンテナ名です） サンプルプログラムの実行 ログイン画面の表示 dls_sample_202507コンテナ上の bash から次のコマンドを実行します。 streamlit run src/app.py Webブラウザから http://localhost:8501/ にアクセスしてください。 ユーザーごとの動作確認 user1での動作確認 まず、user1でログインします。パスワードは config.yaml に記載したものを入力してください。 ログインに成功すると、検索画面へ遷移します。 [Search]ボタンを押してください。 user1が参照可能なドキュメントのみが検索されます。 動作確認が終わったら、[Logout]ボタンを押してログアウトします。 user2での動作確認 同様に、user2でも動作確認します。 user2でログインします。パスワードは config.yaml に記載したものを入力してください。 ログインに成功すると、検索画面へ遷移します。 [Search]ボタンを押してください。 user2が参照可能なドキュメントのみが検索されます。 [Logout]ボタンを押してログアウトします。 user3での動作確認 同様に、user3でも動作確認します。 user3でログインします。パスワードはconfig.yamlに記載したものを入力してください。 ログインに成功すると、検索画面へ遷移します。 [Search]ボタンを押してください。 user3が参照可能なドキュメントのみが検索されます。 [Logout]ボタンを押してログアウトします。 user4での動作確認 最後に、user4で動作確認します。 user4でログインします。パスワードはconfig.yamlに記載したものを入力してください。 ログインに成功すると、検索画面へ遷移します。 [Search]ボタンを押してください。 user4が参照可能なドキュメントのみが検索されます。 [Logout]ボタンを押してログアウトします。 注記: 停止ボタンは用意していないため、停止させたい場合はCtrl+Cを押すなどの操作を行ってください。 関連情報 Connector における Document Level Security Elasticsearchには、Connectorという機能があります。 Connectorを利用すると、Amazon S3 や SharePoint Online など外部に存在するファイルをElasticsearch に取り込んで検索できるようになります。 その際、いくつかの Connector では Document Level Security に対応しており、ユーザーの読み取り権限に応じた検索が可能です。 例）ServiceNowなど。 詳細は、Elasticsearch の Connector のドキュメントを参照してください。 https://www.elastic.co/docs/reference/search-connectors/ Field Level Security Document Level Security 以外にも、Field Level Security の機構も用意されています。 これは、「このフィールドに対しては、このユーザーは参照可能、このユーザーは参照不可」といった制御が可能です。 詳細は、Elasticsearch の Field Level Security のドキュメントを参照してください。 https://www.elastic.co/docs/deploy-manage/users-roles/cluster-or-deployment-auth/controlling-access-at-document-field-level#field-level-security まとめ Elasticsearch の Document Level Security 機能を使うと、ユーザーの読み取り権限に応じてドキュメントが検索されることを確認できました。 前回のインデックス単位の権限設定と組み合わせることで、情報漏洩を防ぎつつ、適切な権限を持つユーザーのみが検索できるように設定することが可能です。 ここでは、分かりやすくするために、Dev Tools の Console からAPIキーの生成リクエストを発行する方法を採用しました。 なお、 https://www.elastic.co/docs/reference/search-connectors/es-dls-e2e-guide の例では、 1) .search-acl-filter-source1および.search-acl-filter-source2インデックスに各ユーザーごとの権限情報をドキュメントとして格納しておく。 2) その内容（権限情報）をGET /index-name/_doc/userId で取得する。 3) 取得した内容（権限情報）を元に Create API Key のリクエストを実行して一時的なAPIキーを生成する。 といった手順で APIキーを生成しています。 ↩︎ The post Elasticsearchのドキュメントごとのアクセス制御（Document Level Security） first appeared on Elastic Portal .

目次 はじめに 対象者 できるようになること 前提条件 接続方法 サンプルプログラムのソースコードの取得 Elasticsearch の Endpoint URL の取得 API Key の作成 ビルド～ コンテナとの接続 ビルド コンテナの起動 コンテナとの接続 サンプルプログラムの実行 ログイン画面の表示 ユーザーごとの動作の確認 まとめ はじめに Elasticsearchのインデックスに対するアクセス制御（Kibana上での動作確認） では、Kibana にログインしたユーザーで各インデックスに対するアクセス権を確認しました。 今回は、Python などから API 経由で操作する場合の設定方法について説明します。 なお、本ブログで動かすサンプルアプリケーションは、下記で公開しています。 https://github.com/sios-elastic-tech/blogs/tree/main/2025-06-rbac 対象者 Elasticsearch 熟練度 : 初級者～中級者 Elasticsearch License : Basic 以上 Elasticsearch Version : 筆者は、8.15.5 で動作確認 できるようになること Elasticsearch で API 経由でインデックス単位でのアクセス制御を行える。 前提条件 Elasticsearchのインデックスに対するアクセス制御（Kibana上での動作確認） に記載した以下の作業を行っておく必要があります。 sales_data_2024, sales_data_2025, hr_data_2024, hr_data_2025 のインデックスを作成しておくこと。 上記のインデックスにドキュメントを登録しておくこと。 sales_data エイリアスを作成しておくこと。 hr_data エイリアスを作成しておくこと。 接続方法 Elasticsearch で、Python などから接続する場合、主に2つの方法があります。 user / password を渡して認証する方法 API Key を渡して認証する方法 今回は、後者の API Key を渡して認証する方法を採用します。 API Key を渡す方法のメリットとデメリットです。 メリット 細やかな権限設定を行える。 API Key の有効期限を設定できる。 デメリット 利用するための API Key を事前に発行しておく必要がある。 サンプルプログラムのソースコードの取得 https://github.com/sios-elastic-tech/blogs  の [<> Code] の Download ZIP を選択します。 blogs-main.zip ファイルがダウンロードされるので、これを展開します。 2025-06-rbac フォルダへ移動します。 cd 2025-06-rbac ※準備作業として必要なリクエストもこの中に含まれています。 相対ファイルパス 説明 es_requests/1_create_index.md インデックスの作成リクエスト es_requests/2_create_index_mapping.md インデックスのフィールド作成リクエスト es_requests/3_create_alias.md エイリアスの作成リクエスト es_requests/4_post_doc.md ドキュメントの登録リクエスト Elasticsearch の Endpoint URL の取得 Elastic の Kibana にログインし、アクセス先となる Endpoint URL を取得します。 取得した URL を app/config.yaml の elasticsearch.endpoint に転記します。 app/config.yaml elasticsearch: endpoint: http://host.docker.internal:9200/ cookie: expiry_days: 1 key: some_signature_key name: some_cookie_name credentials: usernames: sales_user: name: sales_user password: sales_user api_key: xxx== hr_user: name: hr_user password: hr_user api_key: xxx== sales_and_hr_user: name: sales_and_hr_user password: sales_and_hr_user api_key: xxx== ※このサンプルでは、Docker 内のコンテナ上で動作している Elasticsearch にアクセスするようにしています。 ※各ユーザーの password は、Streamlit 上で動作するアプリへのログインパスワードです。 適宜、適切なパスワードに置き換えてください。 API Key の作成 API Key を利用して認証を行う場合、事前に API Key を発行しておく必要があります。(*脚注1) 1 Elastic の Kibana にログインし、DevTools の Console から、下記のリクエストを発行します。 (es_requests/5_create_api_key.md にも記載しています。) POST /_security/api_key { "name": "sales_user_20250616", "expiration": "10d", "role_descriptors": { "sales_data_read": { "cluster": ["all"], "indices": [ { "names": ["sales_data*"], "privileges": ["read"] } ] } } } ※”sales_data”で始まるインデックスおよびエイリアスへの読み取り権限を与えます。 有効期限は、10日間としています。(*脚注2) 2 成功すると、次のようなレスポンスが返却されます。 { "id": ""*****************", "name": "sales_user_20250616", "expiration": 1750916489855, "api_key": "*****************", "encoded": "**************************************==" } ここで重要な値は、最後の encoded です。 一度しか表示されないので、app/config.yaml の sales_user の api_key に copy & paste しておきます。 同様に、hr_user 用の API Key も生成します。 リクエスト POST /_security/api_key { "name": "hr_user_20250616", "expiration": "10d", "role_descriptors": { "hr_data_read": { "cluster": ["all"], "indices": [ { "names": ["hr_data*"], "privileges": ["read"] } ] } } } レスポンス { "id": ""*******************", "name": "hr_user_20250616", "expiration": 1750917110752, "api_key": "*******************", "encoded": "********************************==" } encoded に表示された値を、app/config.yaml の hr_user の api_key に copy & paste しておきます。 最後に、sales と hr 両方の読み取り用 API Key を発行します。 リクエスト POST /_security/api_key { "name": "sales_and_hr_user_20250616", "expiration": "10d", "role_descriptors": { "sales_and_hr_data_read": { "cluster": ["all"], "indices": [ { "names": ["sales_data*", "hr_data*"], "privileges": ["read"] } ] } } } レスポンス { "id": """**********************", "name": "sales_and_hr_user_20250616", "expiration": 1750917246202, "api_key": ""**********************", "encoded": "********************************************==" } encoded に表示された値を、app/config.yaml の sales_and_hr_user の api_key に copy & paste しておきます。 ビルド～ コンテナとの接続 ビルド docker-compose.yml があるディレクトリへ移動します。 cd app docker-compose.yml があるディレクトリで下記を実行します。 docker compose build コンテナの起動 docker compose up -d コンテナとの接続 docker exec -it rbac_sample_202506 /bin/bash (“rbac_sample_202506″はコンテナ名) サンプルプログラムの実行 ログイン画面の表示 rbac_sample_202506 コンテナ上の bash から次のコマンドを実行します。 streamlit run src/app.py Web ブラウザから  http://localhost:8501/  にアクセスします。 ユーザーごとの動作の確認 sales_user まず、sales_user でログインします。 パスワードは config.yaml に記載したものを入力します。 成功すると、検索画面へ遷移します。 [search sales_data] ボタンを押します。 sales_data* インデックスへの読み取り権があるので、成功します。 続いて [search hr_data] ボタンを押します。 hr_data* インデックスへの読み取り権がないため、エラーとなります。 この動きを図式化すると以下のような図になります。 動作確認が終わったら、[Logout] ボタンを押してログアウトします。 2. hr_user 同様に hr_user でも動作確認します。 hr_user でログインします。 パスワードは config.yaml に記載したものを入力します。 成功すると、検索画面へ遷移します。 [search sales_data] ボタンを押します。 sales_data* インデックスへの読み取り権がないため、エラーとなります。 続いて [search hr_data] ボタンを押します。 hr_data* インデックスへの読み取り権があるので、成功します。 [Logout] ボタンを押してログアウトします。 3. sales_and_hr_user 最後に sales_and_hr_user で動作確認します。 sales_and_hr_user でログインします。 パスワードは config.yaml に記載したものを入力します。 成功すると、検索画面へ遷移します。 [search sales_data] ボタンを押してみます。 sales_data* インデックスへの読み取り権があるので、成功します。 続いて [search hr_data] ボタンを押します。 hr_data* インデックスへの読み取り権があるので、成功します。 [Logout] ボタンを押してログアウトします。 ※停止ボタンは用意していないので、停止させたい場合は Ctrl+C を押すなどの処置を行ってください。 まとめ Python などのプログラムからアクセスする場合に、適切な権限を設定した API Key を使って接続することにより、 インデックスごとの権限を考慮したアクセスができることを紹介しました。 今回は、インデックスごとのアクセス権限の制御の方法について紹介しましたが、 ドキュメントごとのアクセス権限を制御する方法もあります。 こちらについては、日をあらためて紹介したいと思います。 今回は簡易なサンプルなので、あらかじめ Dev Tools の Console で 上記リクエストを発行し、API Key を作成していますが、 ログインするたびにAPI Key を生成するリクエストを発行し、有効期限が短い API Key を生成する方法も考えられます。 ただし、そのような仕組みにしようとすると、本ブログで説明するには複雑な構成になってしまうため、 ここでは簡易的な仕組みとしています。 ※API Key を発行するためには、API Key を発行する権限（manage_api_key）を持ったユーザーをあらかじめ作成しておく必要があります。 また、そのユーザーに接続するには API Key ではなく user / password による認証が必要です。 ↩︎ 有効期限を過ぎた API Key は、invalidated: true となり使用できなくなります。その後、おおよそ24時間後に削除されます。 https://www.elastic.co/docs/reference/elasticsearch/configuration-reference/security-settings ↩︎ The post Elasticsearchのインデックスに対するアクセス制御（API経由での動作確認） first appeared on Elastic Portal .

目次 はじめに 対象者 できるようになること ロール(Role)の作成 ユーザー(User)の作成 インデックスの作成 インデックスのフィールドの作成 インデックスへのエイリアスの作成 ドキュメントの登録 ユーザーごとの動作確認 まとめ はじめに Elasticsearchのインデックスに対するアクセス制御（概要 ） で Elasticsearch におけるロールベースのアクセス制御（RBAC）の概要について説明しました。 今回は、実際にロールとユーザーを作成して、Kibana上での実際の動作を確認していきます。 対象者 – Elasticsearch 熟練度 : 初級者～中級者 – Elasticsearch License : Basic 以上 – Elasticsearch Version : 筆者は、8.15.0 で動作確認 できるようになること – Elasticsearch でインデックス単位でのアクセス制御を行える。 ロール(Role)の作成 まず、 Elasticsearchのインデックスに対するアクセス制御（概要 ） のパターン1、パターン2 で示したようなロールを作成していきます。 作成するロールは、以下の3つです。 ロール名 対象インデックス 許可する操作 sales_user_role sales_data* read, view_index_metadata hr_user_role hr_data* read, view_index_metadata sales_and_hr_manager_role sales_data*, hr_data* all elastic ユーザーで Kibana にログインし、Dev Tools の Console から以下のリクエストを発行して、上記の3つのロールを作成します。(*1) 1 POST /_security/role/sales_user_role { "cluster": [ "all" ], "indices": [ { "names": ["sales_data*"], "privileges": ["read","view_index_metadata"] } ], "applications": [ { "application": "kibana-.kibana", "privileges": [ "space_all" ], "resources": [ "space:default" ] } ], "run_as": [], "metadata": {}, "transient_metadata": { "enabled": true } } POST /_security/role/hr_user_role { "indices": [ { "names": ["hr_data*"], "privileges": ["read","view_index_metadata"] } ], "applications": [ { "application": "kibana-.kibana", "privileges": [ "space_all" ], "resources": [ "space:default" ] } ], "run_as": [], "metadata": {}, "transient_metadata": { "enabled": true } } POST /_security/role/sales_and_hr_manager_role { "cluster": [ "all" ], "indices": [ { "names": ["hr_data*", "sales_data*"], "privileges": ["all"] } ], "applications": [ { "application": "kibana-.kibana", "privileges": [ "space_all" ], "resources": [ "space:default" ] } ], "run_as": [], "metadata": {}, "transient_metadata": { "enabled": true } } ユーザー(User)の作成 Elasticsearchのインデックスに対するアクセス制御（概要 ） のパターン1、パターン2 で示したようなユーザーを作成していきます。 作成するユーザーは、以下の4人です。 ユーザー名 保持するロール sales_user1 sales_user_role hr_user2 hr_user_role sales_and_hr_user3 sales_user_role, hr_user_role sales_and_hr_manager6 sales_and_hr_manager_role Dev Tools の Console から以下のリクエストを発行して、上記の4つのユーザーを作成します。(*2) 2 PUT /_security/user/sales_user1 { "password": "secret_password", "roles": ["sales_user_role"] } PUT /_security/user/hr_user2 { "password": "secret_password", "roles": ["hr_user_role"] } PUT /_security/user/sales_and_hr_user3 { "password": "secret_password", "roles": ["sales_user_role", "hr_user_role"] } PUT /_security/user/sales_and_hr_manager6 { "password": "secret_password", "roles": ["sales_and_hr_manager_role"] } “secret_password” については、適宜、適切なパスワードに置き換えてください。 インデックスの作成 Elasticsearchのインデックスに対するアクセス制御（概要 ） のパターン1、パターン2 で示したようなインデックスを作成していきます。 作成するインデックスは、下記の4つです。 インデックス名 説明 sales_data_2024 2024年分の営業データ sales_data_2025 2025年分の営業データ hr_data_2024 2024年分の人事データ hr_data_2025 2025年分の人事データ Dev Tools の Console から以下のリクエストを発行して、上記の4つのインデックスを作成します。 PUT /sales_data_2024 { "settings": { "index": { "number_of_shards": 1, "number_of_replicas": 1 } } } PUT /sales_data_2025 { "settings": { "index": { "number_of_shards": 1, "number_of_replicas": 1 } } } PUT /hr_data_2024 { "settings": { "index": { "number_of_shards": 1, "number_of_replicas": 1 } } } PUT /hr_data_2025 { "settings": { "index": { "number_of_shards": 1, "number_of_replicas": 1 } } } インデックスのフィールドの作成 さきほど作成したインデックスへフィールドを作成していきます。 今回は、あくまでもアクセス権の確認のためのインデックスなので、必要最低限のフィールドのみとし、形態素解析については省略します。 4つのインデックスそれぞれに、以下の2つのフィールドを作成します。 フィールド名 フィールドタイプ 説明 @timestamp date ドキュメントの登録日時 content text ドキュメントの内容 Dev Tools の Console から以下のリクエストを発行して、上記の2つのフィールドを作成します。 PUT /sales_data_2024/_mapping { "properties": { "@timestamp": { "type": "date" }, "content": { "type": "text" } } } PUT /sales_data_2025/_mapping { "properties": { "@timestamp": { "type": "date" }, "content": { "type": "text" } } } PUT /hr_data_2024/_mapping { "properties": { "@timestamp": { "type": "date" }, "content": { "type": "text" } } } PUT /hr_data_2025/_mapping { "properties": { "@timestamp": { "type": "date" }, "content": { "type": "text" } } } インデックスへのエイリアスの作成 sales_data_2024, sales_data_2025, hr_data_2024, hr_data_2025 という4つのインデックスを作成しました。 このままでも操作は可能ですが、さらに操作しやすくなるよう、インデックスに対するエイリアスを作成します。 作成するエイリアスは以下の2つです。 エイリアス 対象となるインデックス名 sales_data sales_data_* hr_data hr_data_* Dev Tools の Console から以下のリクエストを発行して、上記の2つのエイリアスを作成します。 POST _aliases { "actions": [ { "add": { "index": "sales_data_*", "alias": "sales_data" } }, { "add": { "index": "hr_data_*", "alias": "hr_data" } } ] } ※最初にロールを作成しました。そのロールの中で対象インデックスを “sales_data*”, “hr_data*” と指定しましたが、これには今回作成したエイリアスも含まれます。 “sales_data*” に対する read 権限、というのは、   – sales_data_2024 インデックスへの読み取り権限   – sales_data_2025 インデックスへの読み取り権限 に加えて、   – sales_data エイリアスに対する読み取り権限 があることを意味します。 ドキュメントの登録 インデックスを作成したので、次はインデックスへドキュメントを登録します。 sales_and_hr_manager6 ユーザーに sales_data* インデックス、および hr_data* インデックスへの all 権限を与えているので、動作確認も兼ねて sales_and_hr_manager6 ユーザーで Kibana にログインし、ドキュメントを登録していきます。 POST /sales_data_2024/_doc { "@timestamp": "2024-01-10", "content": "これは 2024-01-10の営業資料です。" } POST /sales_data_2025/_doc { "@timestamp": "2025-01-11", "content": "これは 2025-01-11の営業資料です。" } POST /hr_data_2024/_doc { "@timestamp": "2024-01-12", "content": "これは 2024-01-12の人事の資料です。" } POST /hr_data_2025/_doc { "@timestamp": "2025-01-13", "content": "これは 2025-01-13の人事の資料です。" } ドキュメントが問題なく登録されます。 ユーザーごとの動作確認 ドキュメントを登録したので、ユーザーごとに動作確認していきます。 1. sales_and_hr_manager6 ユーザー sales_and_hr_manager6 ユーザーでログインしているので、引き続き、検索も実行してみます。 GET /sales_data,hr_data/_search 登録した4件すべてのドキュメントがヒットします。 2. sales_user1 ユーザー 次に、sales_user1 ユーザーでログインしなおします。 sales_data インデックスに対する検索クエリーを発行してみます。 GET /sales_data/_search sales_data_2024, sales_data_2025 インデックスのドキュメントがヒットします。 次に hr_data インデックスに対する検索クエリーを発行してみます。 GET /hr_data/_search すると、hr_data* インデックスへの読み取り権が不足しているため、以下のようなエラーが返却されます。 { "error": { "root_cause": [ { "type": "security_exception", "reason": "action [indices:data/read/search] is unauthorized for user [sales_user1] with effective roles [sales_user_role] on indices [hr_data], this action is granted by the index privileges [read,all]" } ], "type": "security_exception", "reason": "action [indices:data/read/search] is unauthorized for user [sales_user1] with effective roles [sales_user_role] on indices [hr_data], this action is granted by the index privileges [read,all]" }, "status": 403 } ためしに、sales_data_2025 インデックスへのドキュメントの登録リクエストを発行してみます。 POST /sales_data_2025/_doc { "@timestamp": "2025-06-13", "content": "これは 2025-06-13の営業資料です。" } sales_data* インデックスへの書き込み権がないので、以下のようなエラーとなります。 { "error": { "root_cause": [ { "type": "security_exception", "reason": "action [indices:data/write/index] is unauthorized for user [sales_user1] with effective roles [sales_user_role] on indices [sales_data_2025], this action is granted by the index privileges [create_doc,create,index,write,all]" } ], "type": "security_exception", "reason": "action [indices:data/write/index] is unauthorized for user [sales_user1] with effective roles [sales_user_role] on indices [sales_data_2025], this action is granted by the index privileges [create_doc,create,index,write,all]" }, "status": 403 } 3. hr_user2 ユーザー 同様に、hr_user2 ユーザーでログインし、検索リクエストを発行してみます。 GET /sales_data/_search sales_data* インデックスへの読み取り権がないため、エラーとなります。 GET /hr_data/_search こちらは、hr_data_2024 インデックス、hr_data_2025 インデックス 内のドキュメントがヒットします。 ためしに、hr_data_2025 インデックスへのドキュメントの登録リクエストを発行してみます。 POST /hr_data_2025/_doc {   "@timestamp": "2025-06-13",   "content": "これは 2025-06-13の人事の資料です。" } hr_data* インデックスへの書き込み権がないので、エラーとなります。 4. sales_and_hr_user3 ユーザー 最後に sales_and_hr_user3 ユーザーでログインし、検索リクエストを発行してみます。 GET /sales_data,hr_data/_search sales_data_2024, sales_data_2025, hr_data_2024, hr_data_2025 インデックスのドキュメントすべてがヒットします。 ためしに、ドキュメントの登録リクエストを発行してみます。 POST /sales_data_2025/_doc"@timestamp": "2025-06-13", "content": "これは 2025-06-13の営業資料です。" } POST /hr_data_2025/_doc { "@timestamp": "2025-06-13", "content": "これは 2025-06-13の人事の資料です。" } sales_data* インデックス、hr_data* インデックス、ともに書き込み権がないため、いずれもエラーとなります。 以上の4つのユーザーでの動作をまとめると以下の表になります。 ユーザー sales_data* インデックスへの操作 hr_data* インデックスへの操作 sales_user1 〇読み取り可 ×読み書き不可 hr_user2 ×読み書き不可 〇読み取り可 sales_and_hr_user3 〇読み取り可 〇読み取り可 sales_and_hr_manager6 ◎読み書き可 ◎読み書き可 まとめ このように、ロールベースのアクセス制御を活用することにより、インデックスごとのアクセス制御ができることが確かめられました。 実際の現場でも要件に合わせて、ロールを適切に設定することで、情報漏洩やデータの破損などのリスクを軽減できることをおわかりいただけたかと思います。 API からリクエストを発行する方法以外に、Kibana からロールを作成することも可能です。 このリクエスト内には、インデックスへの操作以外に、applications などの指定も行っています。 厳密には、これらのアクセス権についても、きちんと考慮する必要がありますが、 今回はインデックスへのアクセス権を確かめることを目的としているので、これらについては深く掘り下げません。 ↩︎ API からリクエストを発行する方法以外に、Kibana からユーザーを作成することも可能です。 ↩︎ The post Elasticsearchのインデックスに対するアクセス制御（Kibana上での動作確認） first appeared on Elastic Portal .

目次 はじめに 対象者 なぜインデックスレベルのアクセス制御が必要なのか？ Elasticsearchにおけるインデックスアクセス制御の仕組み 1. ロール (Role) の定義 2. ユーザー (User) の作成とロールの割り当て 主要な権限（Privileges）の種類 まとめ はじめに Elasticsearchは、その柔軟性とスケーラビリティから、多種多様なデータを扱うための中心的なプラットフォームとして多くの企業で利用されています。 しかし、データ量が増え、利用者が多様化するにつれて、「誰がどのデータにアクセスできるのか」というセキュリティの課題が極めて重要になります。 今回は、Elasticsearchにおけるインデックスに対するアクセス制御の概要について説明します。 これは、データのセキュリティを確保するための最も基本的な、しかし非常に強力な機能です。 対象者 Elasticsearch : 初級者～中級者 License : Basic 以上 Version : 筆者は、8.15 で確認 なぜインデックスレベルのアクセス制御が必要なのか？ Elasticsearchは、データを「インデックス」という単位で管理します。 このインデックスは、リレーショナルデータベースにおける「テーブル」のようなものと考えることができます。 複数のインデックスが存在する場合、それぞれのインデックスには異なる種類のデータや、異なる機密レベルのデータが含まれていることがほとんどです。 例えば、以下のようなケースが考えられます。 部門ごとのデータ 営業部門のデータ 人事部門のデータ 開発部門のデータ これらがそれぞれ異なるインデックスに格納されているとします。 このような状況で、全てのユーザーが全てのインデックスにアクセスできるのは望ましくありません。 誤操作によるデータ破壊や、不正な情報漏洩のリスクを最小限に抑えるためには、適切なアクセス制御が不可欠です。 Elasticsearchにおけるインデックスアクセス制御の仕組み Elasticsearchでは、主にロールベースのアクセス制御 (RBAC = Role bases access control) を用いて、インデックスに対するアクセスを管理します。 1. ロール (Role) の定義 ロールは、特定の権限の集合体です。例えば、「読み取り専用ユーザーロール」「管理者ロール」「人事部門データ閲覧ロール」など、業務や役割に基づいてロールを定義します。 ロール定義の際に、どのインデックスに対して、どのような操作（読み取り、書き込み、管理など）を許可するかを指定します。 PUT /_security/role/sales_user_role { "indices": [ { "names": ["sales_data*"], # sales_dataで始まる全てのインデックス（複数指定可） "privileges": ["read", "view_index_metadata"] # 読み取りとインデックスメタデータの閲覧を許可（複数指定可） } ], ... } 上記の例では、sales_user_role というロールを持つユーザーは、sales_data で始まる全てのインデックスに対して「読み取り」と「インデックスメタデータの閲覧」のみが許可されます。(*1) 1 2. ユーザー (User) の作成とロールの割り当て 次に、実際にElasticsearchにアクセスするユーザーを作成し、作成したロールをそのユーザーに割り当てます。 POST /_security/user/sales_user1 { "password": "your_secure_password", "roles": ["sales_user_role"] # ロールを割り当て（複数指定可） } sales_user1は、sales_user_role の権限を持つことになります。(*2) 2 ロールとユーザーとインデックスの関係を表した概念図を以下に記載します。 ロールとユーザーとンデックスの関係を図式化した例を２つ下記に挙げます。 ロールとユーザーの関係図（パターン1） sales_user1 は、sales_user_role を持ちます。sales_user_role があるため、sales_data* のインデックスの読み取りが可能です。 hr_user2 は hr_user_role を持ちます。hr_user_role があるため、hr_data* のインデックスの読み取りが可能です。 sales_and_hr_user3 は、sales_user_role と hr_user_role を持ちます。sales_user_role と hr_user_role があるため、sales_data* および hr_data* インデックスの読み取りが可能です。 2. ロールとユーザーの関係図（パターン2） sales_user4 は、sales_user_role を持ちます。sales_user_role があるため、sales_data* のインデックスの読み取りが可能です。 hr_user5 は hr_user_role を持ちます。hr_user_role があるため、hr_data* のインデックスの読み取りが可能です。 sales_and_hr_manager6 は、hr_and_sales_manager_role を持ちます。hr_and_sales_manager_role があるため、sales_data* および hr_data* インデックスへの読み書きが可能です。 主要な権限（Privileges）の種類 インデックスに対して割り当てられる主な権限には、以下のようなものがあります。(*3) 3 read: ドキュメントの検索、取得を許可します。 write: ドキュメントの追加、更新、削除を許可します。 delete: ドキュメントの削除を許可します。 create_index: 新しいインデックスの作成を許可します。 manage: インデックス設定の変更、エイリアスの管理など、インデックスレベルの管理操作を許可します。 all: そのインデックスに対する全ての操作を許可します（管理者権限）。 view_index_metadata: インデックスのメタデータ（マッピングなど）の閲覧を許可します。 これらの権限を適切に組み合わせることで、きめ細やかなアクセス制御を実現できます。 アクセス制御におけるベストプラクティス 最小権限の原則 (Principle of Least Privilege): ユーザーには、その業務を遂行するために必要最小限の権限のみを付与するべきです。安易に all 権限や広範なインデックスへのアクセスを許可しないようにしましょう。 明確なロールの定義: ロールは、そのロールが持つべき権限を明確に反映するように命名し、定義します。 定期的なレビュー: アクセス制御の設定は、組織の変更やデータ要件の変更に合わせて定期的にレビューし、必要に応じて更新することが重要です。 ワイルドカードの活用: sales_data* のようにワイルドカードを使用することで、将来的に追加される類似のインデックスに対しても自動的にアクセス制御を適用できます。 X-Packセキュリティの活用: これらのアクセス制御機能は、ElasticsearchのX-Packセキュリティ（有償ライセンスが必要）によって提供されます。本番環境での利用には必須の機能と言えるでしょう。 まとめ Elasticsearchにおけるインデックスに対するアクセス制御は、データのセキュリティと整合性を保つ上で非常に重要です。 ロールベースのアクセス制御を適切に設計・適用することで、不正アクセスやデータ漏洩のリスクを大幅に軽減し、より安全なデータプラットフォームを構築することができます。 Elasticsearchでデータを扱う際には、アクセス制御の設計と実装を最優先事項の一つとして考慮に入れるようにしましょう。 次回は、実際の動きを交えて説明します。 例示した内容以外にも、様々な設定を行うことが可能です。 詳細は、公式ドキュメントを参照してください。 https://www.elastic.co/docs/deploy-manage/users-roles/cluster-or-deployment-auth/user-roles また、API を発行する以外にも、Kibana からロールを作成することも可能です。 https://www.elastic.co/docs/deploy-manage/users-roles/cluster-or-deployment-auth/kibana-role-management ↩︎ 例示した内容以外にも、様々な設定を行うことが可能です。 詳細は、公式ドキュメントを参照してください。 https://www.elastic.co/docs/api/doc/elasticsearch/operation/operation-security-get-user また、API を発行する以外にも、Kibana からユーザーを作成することも可能です。 https://www.elastic.co/docs/deploy-manage/users-roles/cluster-or-deployment-auth/quickstart#_create_a_user ↩︎ ここに示した以外にも、様々な Privilege が用意されています。 詳細は、公式ドキュメントを参照してください。 https://www.elastic.co/docs/deploy-manage/users-roles/cluster-or-deployment-auth/elasticsearch-privileges#privileges-list-indices ↩︎ The post Elasticsearchのインデックスに対するアクセス制御（概要） first appeared on Elastic Portal .

ElasticsearchとKibana Mapsを使い、東京都犯罪データの位置情報をローコードで可視化する方法を解説します。また、Logstashによる効率的なデータ取り込み手順も紹介します。 目次 なぜ位置情報が重要なのか Elastic Stackによる位置情報可視化の概要 Elastic Mapsとは データ準備 リアルタイムデータ取り込み: Python vs Logstashによるアプローチ Pythonによるデータ投入 Logstashによるデータ取り込み（ローコード実装） Kibana Mapsでの可視化 ベースマップの追加 データレイヤー（ドキュメント）の追加 クラスタレイヤーの追加とタイムスライダーの活用 ダッシュボードでの活用とフィルタリング スケーラビリティのポイント セキュリティの考慮事項 まとめ 使用環境・ツールバージョン なぜ位置情報が重要なのか 位置情報は単なる点の座標データに留まりません。リアルタイム分析と組み合わせることで、以下のような価値あるインサイトが生まれます。 交通・MaaS : リアルタイムな混雑状況の把握や最適ルートの提案により、移動の効率化と利用者満足度の向上が可能。 物流 : 配送ルートの最適化や燃料コスト削減など、輸送効率を最大化。トラックや荷物の リアルタイムトレーシング により遅延やロスを迅速に検知できます。 AIデバイス・セキュリティ :  リアルタイムトレーシング によるデバイスや人の動態監視で異常検知や侵入警告を実現。設備の稼働状況を地図上で把握し、効率的な管理やメンテナンス計画に役立てられます。 このように、位置情報×リアルタイム分析は様々な業界で意思決定を支える重要な手法となっています。 Elastic Stackによる位置情報可視化の概要 Elastic Stackは、統合的なデータ収集・分析基盤です。本ブログで用いる主要コンポーネントは次のとおりです。 Elasticsearch : スケーラブルで高速な検索・分析エンジン。位置情報を含む大規模データの格納と集計に適しています。 Kibana : Elasticsearch上のデータを可視化・分析するためのダッシュボードツール。地理空間データ向けのMaps機能を備え、GUI操作で多彩なビジュアル化が可能です。 Logstash : 多様なデータソースからのデータ収集・変換・送信を行うパイプラインツール。CSVなど構造化データの読み込みやリアルタイムデータ取り込みに適しており、シンプルな設定でElasticsearchへのデータ投入を自動化できます。 これらを組み合わせることで、大量の位置情報データをリアルタイムに取り込みつつ（Logstash）、それを高速検索エンジン（Elasticsearch）に蓄積し、最後にダッシュボード（Kibana）で地図可視化するという一連の流れが実現できます。 Elastic Mapsとは Elastic MapsはKibanaに統合された地理空間データ可視化ツールです。Elasticsearchに格納された位置情報をインタラクティブな地図上にポイントやシェイプ、ヒートマップなどの形式で表示し、直感的な分析を可能にします。主な特徴をまとめると: 地理空間分析 : IPアドレス由来の位置、GPS座標、行政区画ポリゴンなど、多様な地理情報を可視化できる。 インタラクティブマップ : マップ上でのズーム・パン操作やフィルタリングにより、興味深いデータポイントを動的に探索可能。 レイヤー機能 : 複数のデータレイヤーを重ねて表示し、多角的な分析を実現（例: ポイントデータ＋エリア境界＋ヒートマップを同一マップ上に重ねる）。 リアルタイム更新 : データがElasticsearchに追加・更新されると、マップ表示にも即時反映されるリアルタイム連携。 カスタマイズ性 : ポイントの色やシンボル、サイズ、ラベル表示などを柔軟に設定可能。用途に応じてマップの見せ方を調整できます。 Elastic Mapsは、ネットワーク監視や物流管理、地理的なトレンド分析など幅広い用途で活用されています。利用するには、Elasticsearchのインデックスに地理情報フィールド（ geo_point 型または geo_shape 型）が含まれていることと、Kibana上で当該インデックスにアクセスできることが必要です（※Elasticsearchの動的マッピングでは geo_point を自動認識しないため、後述するように手動でマッピング定義を行います）。 データ準備 今回は、東京都のオープンデータである 犯罪認知数のデータ と、町丁目レベルの 緯度・経度参照データ を使用します。前者には東京都内の各区市町村・町丁目ごとの犯罪件数（罪種別・手口別）が含まれており、後者は各町丁目の代表地点の座標情報です。 データは以下のサイトから取得しました。 区市町村の町丁別、罪種別及び手口別認知件数： https://www.keishicho.metro.tokyo.lg.jp/about_mpd/jokyo_tokei/jokyo/ninchikensu.html 国土数値情報ダウンロードサイト： https://nlftp.mlit.go.jp/cgi-bin/isj/dls/_choose_method.cgi 取得した複数年分（2019年～2024年）のCSVを統合し、分析に適した形に前処理します。具体的には「区」「町丁目」を識別子とし、各罪種別・手口の件数を ワイド形式 （各カテゴリが列）から ロング形式 （各カテゴリが行レコード）へ変換しました。これにより、「区」「町丁」「緯度」「経度」「犯罪種別」「件数」「年」といった列を持つ一つの大きなデータセットを構築しています。件数0のレコードは分析上不要なため除去しました。最終的に約数万行規模のデータ（long_format_crime_data.csv）となりますが、目的はElasticsearchによる地図可視化機能の紹介であり、個々の犯罪傾向の考察は本稿の範囲外とします。 long_format_crime_data ダウンロード リアルタイムデータ取り込み: Python vs Logstashによるアプローチ 大量のCSVデータをElasticsearchに投入する方法として、まずはシンプルにPythonスクリプトを用いる方法と、Elastic Stack標準のLogstashを用いる方法の2つを試しました。それぞれのアプローチについて、実装手順と所感を比較します。 Pythonによるデータ投入 Pythonを使った方法では、 pandas ライブラリでCSVを読み込み前処理した後、ElasticsearchのPythonクライアント（またはREST API）でデータを登録するという手順を取りました。例えば、前述のワイド→ロング変換には以下のようなコードを使用しています。 import pandas as pd # CSV複数ファイルを読み込み結合（2019-2023年分） csv_files = ["crime_2019.csv", "crime_2020.csv", ...] # 各年のCSVファイル名 df_all = pd.concat([pd.read_csv(f) for f in csv_files], ignore_index=True) # ワイド形式をロング形式に変換 df_long = df_all.melt(id_vars=["区", "町丁", "緯度", "経度", "Year"], var_name="CrimeType", value_name="Count") df_long = df_long[df_long["Count"].fillna(0).astype(int) > 0] # 件数0行を除去 変換後の df_long データフレームを1行ずつElasticsearchにインデックスしていきます。シンプルな実装としては以下のようになります。 from elasticsearch import Elasticsearch es = Elasticsearch("http://localhost:9200") # Elasticsearchクライアント for _, row in df_long.iterrows(): doc = { "区": row["区"], "町丁": row["町丁"], "緯度": row["緯度"], "経度": row["経度"], "CrimeType": row["CrimeType"], "Count": int(row["Count"]), "Year": row["Year"], "location": [float(row["経度"]), float(row["緯度"])] # 経度・緯度からgeo_point用配列生成 } es.index(index="all_crimes", document=doc) 上記では各レコードを逐次投入していますが、データ件数が多い場合はかなり時間を要します（数万件規模で数分以上）。Pythonで細かな変換やロジックを実装できる柔軟性は魅力ですが、一件ずつの投入は非効率であり、リアルタイムデータ取り込みには適しません。大量データやストリーミングデータの取り込みには、次に述べるようにElastic Stackのツールを活用する方が効率的です。 Logstashによるデータ取り込み（ローコード実装） Logstashを用いると、煩雑なコードを書くことなく ローコード で大量データの取り込みパイプラインを構築できます。Logstashの設定ファイル（*.conf）にデータソースや処理内容を記述するだけで、CSV読み込みからElasticsearch送信までを自動化してくれます。Python実装と比較すると、大規模データでは 圧倒的に高速 であることが検証できました。 以下に、本稿で使用したLogstash設定ファイルの例を示します。（CSVファイルパスやフィールド名は環境に合わせて適宜読み替えてください。） Logstashの実行方法 bin/logstash -f logstash_crime.conf ※ Elastic Stack を zip からインストールした場合、 bin/logstash  がコマンド。Homebrewなら  logstash -f ... 上記のLogstash設定では、CSVフィルタで各列をパースし、日本語のフィールド名「緯度」「経度」を location_data というオブジェクト配下に整理しています。続いてRubyフィルタで location という geo_point 形式の配列フィールドを生成し（経度・緯度の順に配置）、さらに Year から YearDate という date 型フィールドを作成しています。最後にElasticsearch出力では、作成済みのインデックス all_crimes にデータを書き込みつつ、 pipeline オプションでIngest Pipeline（Elasticsearch側のデータ投入時処理）を指定しています。この remove_raw_fields パイプラインは、CSV読み込み時に付与される生のメッセージフィールド（ message や @version 等）を削除するためのものです。 PUT _ingest/pipeline/remove_raw_fields { "processors": [ { "remove": { "field": "message" }}, { "remove": { "field": "event.original" }} ] } マッピングの設定:  Logstashでデータ投入を行う前に、Elasticsearch側でインデックスのマッピングを用意しておくことが重要です。とくに location や YearDate のように、デフォルトの動的マッピングでは適切な型（geo_pointやdate）にならないフィールドは、あらかじめ明示的に型指定してインデックスを作成します。開発者ツール（Dev Tools）上で以下のようなコマンドを実行し、インデックス all_crimes を作成しました。 PUT all_crimes { "mappings": { "properties": { "location": { "type": "geo_point" }, "YearDate": { "type": "date", "format": "strict_year" }, "CrimeType": { "type": "keyword" }, "CrimeMethod": { "type": "keyword" }, "Count": { "type": "integer" } } } } 以上の設定により、Pythonスクリプトを用いた場合と比べて格段に高速に（体感で数十倍以上）データを投入できました。CSV数万件程度であれば数十秒～1分程度で完了し、Elasticsearchのインデックスにドキュメントが登録されます。Logstashは設定ファイルさえ用意すれば、リアルタイムにファイルを監視して継続的に取り込むことも可能であり、本番環境でも耐えうる柔軟かつ強力なデータ取り込み基盤となります。 Kibana Mapsでの可視化 データの準備と投入が完了したら、いよいよKibanaのMaps機能を使って位置情報データを可視化してみましょう。ここでは、Elasticsearchにロードした all_crimes インデックス上の地理データを地図にプロットし、さらに集計表示や時系列による変化も確認できるダッシュボードを作成します。 ※ 注意：Kibana上での可視化には、対応するData Viewの作成が必要です。 Kibanaは「どのインデックスに、どんな構造のデータがあるか」を認識するために、このData Viewを参照します。忘れずにインデックスに対応するData View を作成しておきましょう。 ベースマップの追加 最初に地図の土台となるベースマップを追加します。Kibanaのナビゲーションメニューから「Maps」 を開き、 「Create map」ボタンをクリックしてください。その後、以下の手順でベースマップレイヤーを設定します。 「Add layer」 → 「EMS Basemaps」 お好みのスタイルを選択しましょう（例えば視認性の高い”Light”スタイルなど） → 「Add and continue」 必要に応じてベースマップの表示設定を調整します。今回は地図をはっきり表示するため「Opacity（不透明度）」を100%に設定し、「Label language」を日本語に変更しました。 「Keep changes」をクリックします。 以上で背景地図となるベースマップが追加されます。選択したスタイルによる白地図が表示され、これからプロットするデータの土台として機能します。 上の図は「Light」スタイルのベースマップを適用した初期状態の画面です。日本全国の地形や道路が薄灰色で描画されており、この上にデータポイントを重ねていきます。ベースマップにはElastic社提供のタイルサービス（EMS）が利用されていますが、自前の地図タイルやシェイプデータを用意して追加することも可能です。 用意している場合はUpload fileからmergeをする必要です。 データレイヤー（ドキュメント）の追加 続いて、Elasticsearchに投入した位置情報データ（犯罪データ）のレイヤーを地図に重ねます。ベースマップと同様に「Add layer」から操作します。手順は次のとおりです。 「Add layer」 → 「Documents」 （Elasticsearchに保存されたドキュメントを直接プロットするレイヤーです） 「Data view」 → 可視化したいものを選択 「Geospatial field」 → 自動的に location が選択されている 「Add and continue」 → 地図上にデータポイントがプロットされ始めます 必要に応じて表示範囲（ズームレベル）を制限できます。例えば本ケースでは東京都付近を詳細表示したいため、「Visibility」を [9, 24] に設定しました。 ポイントを選択した際に表示される詳細情報「Tooltip fields」を設定します。表示したいフィールド（例:  CrimeType 、 Year 、 区 など）を追加します。これにより各ポイントにマウスオーバーすると、選択した項目の値が吹き出しで表示されます。 「Layer style」の項目ではデータポイントの見た目をカスタマイズできます。「Fill color」を適当なカラーグラデーションに設定し（件数に応じて色が変わるよう設定も可能）、「Symbol size」を「By value」に変更して Count （件数）フィールドを指定します。これで犯罪件数が多い地点ほどシンボルが大きく描画されるようになります。必要であれば「Label」欄に Count を指定し、各ポイント上に件数ラベルを直接表示させることもできます。 「Keep changes」をクリックします。 以上の設定により、地図上に東京都内の各地点がプロットされ、それぞれの点について件数や犯罪種別などの情報を確認できるようになります。ポイントの大小や色で事件数の多寡がひと目で分かり、マウスオーバーで詳細な内訳も把握できます。 上図は all_crimes インデックスのドキュメントをポイントレイヤーとして地図にプロットした結果です。町丁目単位の地点ごとに犯罪件数（Count）に応じた大小の青い円で表示しています。また各円内に件数ラベルを表示しているため、密集地帯でもおおよその数値を読み取ることができます（このラベル表示は任意設定です）。地図を拡大縮小したりドラッグしたりすることで、関心エリアを詳細に調べられます。 クラスタレイヤーの追加とタイムスライダーの活用 個々のポイントが多くプロットされる場合、 クラスタリング 機能を使うと可視化が見やすくなります。Kibana Mapsではドキュメントレイヤーとは別にクラスタレイヤーを追加することで、ポイントの密集地を自動的にグルーピングして表示可能です。また時系列データであれば タイムスライダー を使って時間変化をアニメーション再生することもできます。ここでは、件数データの集約表示とタイムスライダーについて説明します。 クラスタレイヤーの追加手順: 「Add layer」→ 「Clusters」 対象Data viewを指定→ 「Add and continue」 「Show as」で集計の形式を選択します。 「Clusters」 （円形のクラスター表示）か「 Grids」 （格子状のグリッド集計）または 「Hexagons」 （六角形グリッド）から選べます。今回はClustersを選択しました。 「Metrics」→ Aggregation → sum → Fieldに Count （「Add metrics」で複数集計も可能） 「Cluster size」（Resolution）でクラスタリングの細かさを調整できます。値を高くすると細かいグリッドでクラスタリングされ、値を低くすると大まかな範囲でまとめられます。デフォルト設定で問題なければそのままで構いません。 「Keep changes」をクリックします。 クラスタレイヤーを適用すると、ポイントが密集しているエリアでは一つの大きな円でまとめて表示されるようになります。円の中の数字はそのクラスタ内の件数合計（今回設定ではCrime件数の総和）を表します。これにより、例えば23区内のどの地域に犯罪が多発しているかを一望でき、分布の傾向を把握しやすくなります。また、ズームインすれば自動的にクラスターが細分化され、ズームアウトすれば再度まとまるといった具合に、可視化の粒度が動的に変化します。 2020年：侵入窃盗忍込み件数 2021年：侵入窃盗忍込み件数 さらに、 タイムスライダー 機能を使うと時間経過に沿ったデータの変化をアニメーション表示できます。今回のデータは年単位の集計値ですが、タイムスライダーを有効にすると地図下部に再生バーが表示され、時系列でデータの増減を確認できます。画面左の時計アイコン（緑の矢印で示したボタン）をクリックするとスライダーが表示され、再生ボタンでアニメーション開始です。 今回のデータは年単位のためスライダーは年刻みとなり、月単位の細かな変化は表現できません（※データに月・日情報があればスライダー設定を変更することで日付単位での再生も可能です）。タイムスライダーを停止した状態で特定の年を選択すれば、その時点のクラスタ分布を静的に分析することもできます。 ダッシュボードでの活用とフィルタリング 作成した地図はKibanaのダッシュボードに組み込んで活用できます。Maps画面右上の「Save」ボタンから地図を保存し、適宜タイトルを付けて保存します。保存時に既存のダッシュボードに追加するか、新規ダッシュボードを作成するオプションがありますので、「Save and add to dashboard」を選択するとよいでしょう。別の場所でこの図を使用する場合は、「Add to library」にチェックを入れましょう。（ライブラリに追加された要素は「Visualize Library」で確認できます。） ダッシュボードでは複数の可視化（グラフや地図）を一画面に配置して総合的に分析できます。Kibanaダッシュボードの強力な点は、 フィルタリングが連動 することです。あるパネルで範囲を絞り込むと、同じダッシュボード上の他の全パネルに一括でそのフィルターが適用されます。これにより、例えば地図上で特定の地域を選択すると、他のグラフやテーブルもその地域のデータにリアルタイムに絞り込まれるため、関連性のある指標を横断的に分析することが可能です。 もう一つの便利な機能が シェイプでの領域フィルター です。地図パネル上で任意の図形を描画し、その範囲内のデータだけにダッシュボード全体をフィルタリングできます。使い方は以下のとおりです。 「Tools」→ 「Draw shape to filter data」 任意の図形を描画。 すると、その描画した図形（ポリゴン）に該当するエリア内のデータだけがフィルターされます。他のグラフパネルも同時にそのフィルター条件が適用された状態に更新されます。 たとえば東京23区西部を囲む長方形を描けば、その範囲に含まれる町丁の犯罪件数データのみが地図および関連グラフに反映されます。フィルター適用中は画面上部に「intersects shape」というフィルターラベルが表示されます。解除したい場合はそのラベルの✖ボタンをクリックすれば元の全データ表示に戻ります。 さらに、ダッシュボードでは地図パネル以外にも通常のフィルターバーやクエリバーが使用可能です。右側のフィルタリングメニューや上部の検索バーにKQL（Kibana Query Language）を書いてフィルターを適用することもできます。（ 例えば、 区 :"世田谷区" and CrimeType : "侵入窃盗(空き巣)" and YearDate >= "2020"  といったクエリを投入すれば、「世田谷区で発生した侵入窃盗（空き巣）が2020年以降に限定」した条件で全パネルを絞り込めます。 ） 最後に、Kibana Mapsの高度な機能としてES|QLを使用したレイヤー追加も挙げられます。今回の例では使用しませんでしたが、Add layer時に「Documents」ではなく「ES|QL」を選ぶことで、Elasticsearchに対してSQLライクなクエリを発行し、その結果を地図レイヤーとして可視化することも可能です。 FROM all_crimes | WHERE 区 IN (“新宿区”, “渋谷区”, “世田谷区”, “港区”, “千代田区”) | KEEP location, crime_type, count, 区 , 町丁 | LIMIT 10000 大量データの集約結果やサブクエリを用いた特殊な可視化を行いたい上級者向けの機能ですが、状況に応じて活用すると分析の幅がさらに広がるでしょう。 スケーラビリティのポイント 位置情報データを継続的に扱うシステムを設計する際には、スケーラビリティ（可搬性・拡張性）の確保が重要です。以下に、本記事の内容を実運用に展開する際に考慮すべきポイントをまとめます。 データ投入パフォーマンス:  今回Logstash経由で高速化を図ったように、より大規模なデータではElasticsearchの Bulk API を活用して一括投入することで効率を上げられます。 インデックス設計:  データ量が膨大になる場合、一つのインデックスに集約しすぎると検索・集計性能が低下します。適切に 時間単位でインデックスを分割 したり（例えば年ごと・月ごとの名前で分割）、Elasticsearchのロールオーバー機能やILM（Index Lifecycle Management）ポリシーを導入して古いデータをアーカイブするといった戦略が有効です。 クラスタリング表示の活用:  Kibana Mapsで非常に多数のポイントを表示するとブラウザ描画が重くなる可能性があります。今回使用した クラスタレイヤー やグリッド表示を活用し、高ズームアウト時には集約表示、ズームイン時に詳細表示とすることでパフォーマンスと可読性を両立できます。 セキュリティの考慮事項 位置情報データはその性質上、個人や組織の行動範囲を含むセンシティブな情報を含む場合があります。Elastic Stackを用いてこれらを可視化・分析する際には、以下のセキュリティ面での対策・配慮が重要です。 アクセス制御:  KibanaダッシュボードやMapsアプリへのアクセスは、Elastic認証機能を利用して適切な権限設定を行いましょう。例えば社内向けポータルとして運用する場合、閲覧できるインデックスやダッシュボードをユーザロールごとに制限し、不要なデータ露出を防ぎます。 – Kibana → 管理 → 「Roles」機能で権限設定 – Userごとに「read」「write」「view_index_metadata」などを設定 プライバシー保護:  個人を特定できる粒度の位置情報（GPS座標や詳細住所など）を扱う際は、必要に応じて匿名化（ジオフェンスで丸める、IDをハッシュ化する等）することを検討してください。 まとめ ElasticsearchとKibana Mapsを活用することで、リアルタイムかつ直感的に位置情報データを可視化・分析できることを見てきました。 リアルタイムデータ取り込み においてはLogstashが大規模データにおいて優れたパフォーマンスを示し、コードを書く手間を少なくしてスピーディーにデータ基盤を構築できる点が確認できました。Kibana Maps上ではポイント表示からクラスタリング、時系列アニメーション、ダッシュボード統合まで豊富な機能をローコードで実現でき、ビジネス課題に応じた柔軟な地理空間分析が可能です。 本ブログでは機能紹介に留まりましたが、実際のユースケースに合わせて応用すれば可能性は非常に広がります。例えば、機械学習を組み合わせて異常な移動パターンを検知したり、ベクター検索技術と統合して位置情報と他の高次元データを関連付けることも考えられます。 位置情報の高速可視化は、今後ますます重要になるリアルタイムデータ活用の一領域です。ぜひ皆さんのプロジェクトでもElasticsearchとKibana Mapsを活用し、地理空間データから新たな価値を引き出してみてください。 使用環境・ツールバージョン 本記事の検証・実装に使用した主なツールのバージョンは以下のとおりです： ツール バージョン Elasticsearch 8.17.3 Kibana 8.17.3 Logstash 8.17.3 Python 3.9.18 ※バージョンによってUIや挙動に差異がある場合があります。あらかじめご了承ください。 The post Kibana MapsとElasticsearchで学ぶ位置情報の可視化手法 first appeared on Elastic Portal .

ECサイトの売上データをもっと活用したいけれど、「SQLでは集計が遅い」「全文検索を使った分析は難しい」「BIツールでは柔軟性に欠ける」と感じたことはありませんか？ そんな課題を一気に解決するのが、 Elasticsearch × Kibana Lens  です。 本記事では、CSV をドラッグ＆ドロップするだけで、 高速かつ柔軟に購買データを可視化・分析 する手順を、サンプルデータと実例つきでわかりやすく紹介します。 目次 記事のポイント 1. SQLと何が違う？Elasticの強みを整理 2. 使うデータと分析の目的 3. インポートと整形 4. Dev Tools上のクエリ例：分析テンプレート集 分析例: 5. Kibana Lensでの可視化 基本的な操作方法 例）性別ごとの売上割合 Create a Runtime Field  6. Elasticが持つAI × 統合分析力 7. まとめ & 次のステップ 記事のポイント 全文検索 × 集計 × 可視化 を 1 スタックで完結 SQL 利用者でも理解できる “発想の違い” を表形式で解説 CSV をドラッグ&ドロップするだけで Kibana Lens ダッシュボードを作成 高額購入者セグメント化／都道府県別売上ランキング など具体例付き コード & サンプルデータ一式があり、追って実装が可能 対象読者 EC サイトの売上データをもっと活用したいデータアナリスト Elasticsearch は聞いたことあるけれど “全文検索の人” というイメージで止まっている方 従来は SQL＋BI ダッシュボードで頑張っているが、レスポンス速度に限界を感じている方 1. SQLと何が違う？Elasticの強みを整理 観点 Elasticsearch (+ Kibana) SQL スケーラビリティ シャード＆ノード追加で水平分散 手動での分割が必要 全文検索 形態素解析 (kuromoji) で日本語も高精度 LIKE ‘%○○%’ でフルスキャン 集計速度 列指向インメモリ計算で TB 級でも数百 ms 行指向 RDB は集計件数に比例して遅延 可視化 Kibana Lens を同梱（ノーコード） 外部 BI ツール必須 リアルタイム性 数秒でインデックス反映 ETL バッチが前提 「SQL が不要」という意味ではなく、“検索・集計・可視化をワンストップで済ませたい” 場面で優位性があります。 2. 使うデータと分析の目的 randomized_customer_data.csv 年齢・性別・地域・商品・購入金額・注文日を含む合成データ 3,000 行 分析シナリオ 顧客セグメント（年齢 × 性別 × 地域） 高額購入者の抽出と特徴把握 都道府県別売上ランキング 商品カテゴリ別トレンド randomized_customer_data ダウンロード 3. インポートと整形 ローカルにインストールしたElasticsearch（本記事ではバージョン8.17.3 を使用）とKibanaを使用し、Pythonは使わずに手動で進めます。 Kibanaの画面上部にある検索バーから「file upload」と入力すると、ファイルアップロード機能が見つかります。Kibanaには多くの機能がありますが、検索画面の利用が最も迅速です。 そこから入ると以下の画面が表示されます アップできるファイルの大きさにリミットがあるので注意してください。 サンプルデータをドラッグ&ドロップ。 ファイルの中身をさらっと確認できます。「import」をクリックして次の画面に行きます。アップロード可能なファイルサイズには制限があります。サンプルデータをドラッグ&ドロップしてください。「import」をクリックすると、ファイルの内容を簡単に確認し、次の画面に進めます。 インデックス名を決定後に「import」をクリックしても良いですが、今回は「Advanced」タブを選択します。「create data view」に自動的にチェックが入っている点に注意してください。 Advancedタブでは、マッピングやIngest pipelineの変更が可能です。今回は3つのデータを削除したいので、Ingest pipelineのremoveで指定します。自動的に不要と判断されたmessageに加えて、firstnameとlastnameも削除対象に追加します。これらはリスト形式で指定します。 // 変更前：Ingest pipeline "remove": { "field": "message" } // 変更後：Ingest pipeline "remove": { "field": ["message", "firstname", "lastname"] } 資料をインポートする際は、まず「import」をクリックしてください。処理が完了すると、「File processed」から「Data view created」にチェックマークがつきます。 もし処理がうまくいかず❌印が表示されます。最後までチェックマークが付いていても、一部データが読み込めなかったというアラートが出る場合もありますので、再試行を推奨します。最後までチェックマークがついたら、インデックス作成は完了しているため、再インデックスを行う前に既存のインデックスを削除する必要があります。 特に注意が必要なのは、インポート時に「create data view」にチェックを入れていた場合、インデックスだけでなくdata viewの削除も必須となる点です。 作成したインデックスが正しく作成されたか確認するには、左側のメニューから「Managment」>「Stack Management」>「Index Mangment」>「Indices」タブを開き、作成したインデックス名が存在するか確認します（上部の検索バーに「index managment」と入力して検索することも可能です）。 インデックスを削除する場合は、同じIndicesタブから実行できます。 データビューを削除したい場合は、検索バーに「data view」と入力してください。 インデックスを削除するには、左側のチェックボックスにチェックを入れ、青いボタンの「Manage index」から「delete index」を選択してください。 データビューで削除したい項目にチェックを入れ、表示されるピンク色のアイコンを選択して削除を実行します。 データのインポートは完了しました。 4. Dev Tools上のクエリ例：分析テンプレート集 Dev Toolsも上部の検索ボックスから検索してスタートできます。 インデックスのmappingを確認します。 GET ec_site/_mapping //_mappingのoutput { "ec_site": { "mappings": { "_meta": { "created_by": "file-data-visualizer" }, "properties": { "@timestamp": { "type": "date" }, "age": { "type": "long" }, "area": { "type": "keyword" }, "areacode": { "type": "long" }, "birthday": { "type": "date", "format": "iso8601" }, "customerid": { "type": "keyword" }, "firstname": { "type": "keyword" }, "lastname": { "type": "keyword" }, "lastorderdate": { "type": "date", "format": "iso8601" }, "product": { "type": "keyword" }, "sex": { "type": "long" }, "totalprice": { "type": "long" } } } } } propertiesにある@timestampはElasticsearchが自動的に追加したもので、その詳細について確認します。 GET ec_site/_search 誕生日フィールドを@timestampとして取ってきているようですが、分析に使わないので、areacodeとセットで落とします。 POST _reindex { "source": { "index":"ec_site" }, "dest": { "index": "ec_site_v1" }, "script": { "lang": "painless", "source": """ ctx._source.remove('@timestamp'); ctx._source.remove('areacode'); """ } } 再度確認いたします。 GET ec_site_v1/_search { "query": { "match_all": {} } } 不要なものが削除されています。 分析例: // 年齢の分布 GET ec_site_v1/_search { "size":0, "aggs":{ "age_dist":{ "histogram":{ "field":"age", "interval":10 } } } } // 性別分布 GET ec_site_v1/_search?filter_path=aggregations <---　アウトプットがaggregation部分だけを表示させる { "size":0, "aggs":{ "by_gender":{ "terms":{ "field": "sex" } } } } // 性別ごとの売上合計 GET /ec_site_v1/_search?filter_path=aggregations { "size": 0, "runtime_mappings": { "sex_label": { ← ラベル用の仮想フィールドを定義 "type": "keyword", "script": { "source": """ if (doc['sex'].size()==0) { emit('不明'); } else if (doc['sex'].value == 1) { emit('男性'); } else if (doc['sex'].value == 2) { emit('女性'); } else { emit('その他'); }""" } } }, "aggs": { "total_sales": { <-- ここで全体売上を集計 "sum": { "field": "totalprice" } }, "sales_by_sex": { <-- 性別ごとの売上集計 "terms": { "field": "sex_label", "order": { "_key": "asc" } }, "aggs": { "sex_sales": { "sum": { "field": "totalprice" } } } } } } // カスタマー分析：高額購入者の傾向 GET /ec_site_v1/_search { "size": 0, "aggs": { "high_value_customers": { "filter": { "range": { "totalprice": { "gt": 70000 } } }, "aggs": { "age_distribution": { "histogram": { "field": "age", "interval": 10 } }, "top_areas": { "terms": { "field": "area.keyword", "size": 3 } }, "gender_ratio": { "terms": { "field": "sex" } } } } } } // 性別ごとの商品カテゴリー分析 GET /ec_site_v1/_search?filter_path=aggregations { "size": 0, "aggs": { "gender": { "terms": { "field": "sex", "size": 3 }, "aggs": { "product_categories": { "terms": { "field": "product.keyword", "size": 10 }, "aggs": { "total_sales": { "sum": { "field": "totalprice" } }, "avg_purchase": { "avg": { "field": "totalprice" } } } } } } } } productを指定のデータのみで集計したい場合、主に二つの方法が考えられます。 GET /ec_site_v1/_search?filter_path=aggregations { "size": 0, "query": { "term": { "product.keyword": "カーテン" } }, "aggs": { "gender": { "terms": { "field": "sex", "size": 3 }, "aggs": { "total_sales": { "sum": { "field": "totalprice" } }, "avg_purchase": { "avg": { "field": "totalprice" } } } } } } GET /ec_site_v1/_search?filter_path=aggregations { "size": 0, "aggs": { "curtain_only": { "filter": { "term": { "product.keyword": "カーテン" } }, "aggs": { "gender": { "terms": { "field": "sex", "size": 3 }, "aggs": { "total_sales": { "sum": { "field": "totalprice" } }, "avg_purchase": { "avg": { "field": "totalprice" } } } } } } } } //商品の絞り込みと性別フィルターを同時にかけたい場合 GET /ec_site_v1/_search?filter_path=aggregations { "size": 0, "query": { "bool": { "filter": [ { "term": { "product.keyword": "カーテン" } }, { "term": { "sex": 2 } } ] } }, "aggs": { "gender": { "terms": { "field": "sex", "size": 3 }, "aggs": { "total_sales": { "sum": { "field": "totalprice" } }, "avg_purchase": { "avg": { "field": "totalprice" } } } } } } // 年齢層による購買分析 GET /ec_site_v1/_search { "size": 0, "aggs": { "age_ranges": { "range": { "field": "age", "ranges": [ { "to": 30, "key": "30歳未満" }, { "from": 30, "to": 50, "key": "30-49歳" }, { "from": 50, "key": "50歳以上" } ] }, "aggs": { "products": { "terms": { "field": "product.keyword", "size": 5 }, "aggs": { "total_sales": { "sum": { "field": "totalprice" } } } }, "avg_purchase": { "avg": { "field": "totalprice" } } } } } } // 商品種類ごとの平均購入金額 GET /ec_site_v1/_search { "size": 0, "aggs": { "products": { "terms": { "field": "product.keyword", "size": 10 }, "aggs": { "avg_price": { "avg": { "field": "totalprice" } } } } } } # リピート顧客分析 (重複ID) GET /ec_site_v1/_search { "size": 0, "aggs": { "unique_customers": { "cardinality": { "field": "customerid.keyword" } }, "total_orders": { "value_count": { "field": "customerid.keyword" } } } } # 上位5都道府県の累計売上 GET /ec_site_v1/_search { "size": 0, "aggs": { "top_5_areas": { "terms": { "field": "area.keyword", "size": 5, "order": { "area_sales": "desc" } }, "aggs": { "area_sales": { "sum": { "field": "totalprice" } } } } } } // 県ごとの売上比較 GET /ec_site_v1/_search { "size": 0, "aggs": { "region_comparison": { "terms": { "field": "area.keyword", "size": 47 }, "aggs": { "total_sales": { "sum": { "field": "totalprice" } }, "order_count": { "value_count": { "field": "customerid.keyword" } } } } } } // 総支出額が最も高いお客様の特定 GET /ec_site_v1/_search { "size": 0, "aggs": { "high_value_customers": { "terms": { "field": "customerid.keyword", "size": 10, "order": { "total_spend": "desc" } }, "aggs": { "total_spend": { "sum": { "field": "totalprice" } } } } } } // 合計価格によるトップ製品 GET /ec_site_v1/_search { "size": 0, "aggs": { "top_products": { "terms": { "field": "product.keyword", "size": 10, "order": { "product_sales": "desc" } }, "aggs": { "product_sales": { "sum": { "field": "totalprice" } } } } } } // 購入額 totalprice の1〜99パーセンタイルを取得し、顧客セグメントのしきい値を一目で把握 GET ec_site_v1/_search { "size":0, "aggs":{ "spending_distribution":{ "percentiles":{ "field": "totalprice", "percents":[1,25,50,75,90,95,99] } } } } // 購入額が高い順に上位10件の顧客ID・購入額・年齢・性別を取得 GET ec_site_v1/_search { "size":10, "sort":[ {"totalprice":"desc"} ], "_source": ["customerid","totalprice","age","sex"] } 5. Kibana Lensでの可視化 Kibana Lensは、ドラッグアンドドロップの簡単な操作で直感的にデータを可視化できるツールです。フィールドの管理、迅速な集計メトリクス、チャートタイプの即時切り替えが可能で、データの検索、フィルタリング、ダッシュボード作成まで柔軟に対応できます。高い技術的スキルがなくても、手軽に高度なデータ分析環境を構築できるのがKibana Lensの魅力です。 Kibana の Lens や Discover では、インデックスそのものではなく Data View を通じてデータにアクセスします。ですので_reindexを使った後、新しいdata viewの登録が必要です。 旧インデックス：ec_site の Data View が存在 新インデックス：ec_site_v1 は 新しい名前のインデックス なので、 既存の Data View では見えません Kibana Lensは、ドラッグアンドドロップ操作で直感的なデータ可視化を実現するツールです。高度な技術がなくても、フィールド管理、迅速な集計、チャートタイプ切り替えにより、容易にデータ分析環境を構築できます。データの検索、フィルタリング、ダッシュボード作成にも柔軟に対応可能です。 KibanaのLensやDiscoverでは、インデックスではなくData Viewを介してデータにアクセスするため、_reindex後に新しいData Viewの登録が必要です。例えば、旧インデックス「ec_site」のData Viewが存在する場合でも、新インデックス「ec_site_v1」は新しい名前のインデックスであるため、既存のData Viewからは参照できません。 Kibanaで、上部の検索ボックスに「lens」と入力してください。 Lensを選択して入ると下の画面が見えます。 基本的な使い方は左側に表示されているデータのフィールドをドラッグ＆ドロップするだけで簡単にチャートを作成することができます。 基本的な操作方法 データビューの選択： ドラップダウンメニューから可視化したいデータビューを選択します。今回、データのアップロード時にビューを使っているのでありますがない場合create a data viewから作成できます。またruntime fieldsを作成したい時にAdd a field to this data viewからできます。 フィールドの選択 ： 左側のパネルには、利用可能なフィールド（例：「年齢」「性別」「商品名」など）が表示されます。目的に合わせて、これらのフィールドを右側のチャート領域へドラッグ＆ドロップします。真ん中にドラッグしてからでも調整できます。 チャートの種類を選択 ： 右側上部のメニューから、棒グラフ（Bar）、折れ線グラフ（Line）など、好きなチャート形式を選択できます。また、積み上げ表示（Stacked）などの表示形式も指定可能です。 軸や集計の設定 ： 「Horizontal axis（横軸）」や「Vertical axis（縦軸）」、さらに「Breakdown（内訳）」などの項目にフィールドをドラッグ＆ドロップして、軸や表示方法を柔軟にカスタマイズできます。 素早い分析とフィルタリング データのフィールドをクリックすると、各項目のトップ値や分布が表示され、即座にデータの傾向を把握できます。さらに、上部の検索バーで特定条件に合致するデータをフィルターすることも可能です。 軸の設定画面。実際に操作をし、各機能の理解を深めることを推奨します。 例）性別ごとの売上割合 割合の表示には用意されている機能だけではできないので、式の採用も必要。 Y軸：totalprice Breakdown: sex Y軸の「Appearance」→「Name」を「合計金額の割合」に設定 Y軸の「Formula」に `sum(totalprice)/overall_sum(sum(totalprice))` を入力 「男」と「女」のみを表示したい場合は、`sex_labes : (“男” or “女”)` を使用 Create a Runtime Field  手順: Kibana に移動し、 Stack Management を選択します。 Data Views を開きます。 目的のData View（例：EC_site）を選択します。 右上にある “Add field” ボタンをクリックします。 以下のフィールドに入力します。 フィールド 名前 タイプ フォーマット スクリプト 値 sex_label Keyword (デフォルトのまま） （下記👇参照） 表に年齢層を表示させたい時には以下の式でscriptを登録できます。 // for making the age group def age = doc['age'].value; if (age >= 15 && age <= 19) emit('15〜19歳'); else if (age >= 20 && age <= 24) emit('20〜24歳'); else if (age >= 25 && age <= 29) emit('25〜29歳'); else if (age >= 30 && age <= 34) emit('30〜34歳'); else if (age >= 35 && age <= 39) emit('35〜39歳'); else if (age >= 40 && age <= 44) emit('40〜44歳'); else if (age >= 45 && age <= 49) emit('45〜49歳'); else if (age >= 50 && age <= 54) emit('50〜54歳'); else if (age >= 55 && age <= 59) emit('55〜59歳'); else if (age >= 60) emit('60歳以上'); else emit('不明'); 作成した様々な図やグラフを一つのダッシュボード機能に統合し、Kibanaの共有機能やレポート機能を活用することで、データ可視化と共有の効率化を図れます。今回のデータセットで作成した図※は、以下のダッシュボードにまとめました。ドラッグ&ドロップでサイズ調整ができるため、目的に応じて容易に活用可能です。 ※ 図表の説明 売上 vs 性別（ラインチャート） ： 　各性別（女性／男性／その他）ごとの総売上額推移を示す。 年齢層 vs 件数（積み上げ棒グラフ） ： 　上位 10 の年齢グループ（例：30–34 歳、35–39 歳…）ごとの購入件数を集計。 　男女別に色分けし、どの世代でどちらの性別が多いかを可視化。 消費金額（ワードクラウド） ： 　都道府県別の総消費金額を文字の大きさで表現。 性別の割合（円グラフ） ： 　全体購入者に占める男女およびその他の比率をパーセンテージで表示。 商品 vs 金額（ラインチャート） ： 　各商品カテゴリ（PC デスク／ソファ／ベッド…など）ごとの平均購入金額を比較。 エリア vs 金額（テーブル） ： 　都道府県ごとに、男性・女性別の購入金額中央値を並べて表示。 注文履歴（時系列ラインチャート） ： 　7 日ごとに集計した総注文金額の推移を示す。 　時間軸を通して売上の増減トレンドを把握可能。 6. Elasticが持つAI × 統合分析力 Elasticは今や「全文検索ツール」ではなく、 AI Search Platform として以下の3領域を提供しています： Search（ベクトル検索・セマンティック検索） Observability（ログ・APM・メトリクス統合） Security（SIEM・脅威検知） 今回のような構造化データだけでなく、 商品説明・レビュー・チャット履歴など非構造データ も、統合AIで文脈を理解した検索が可能です。OpenAIやAmazon Bedrockと連携し、 ベクトル検索による高速類似検索 も標準対応。 さらに、CSVアップロードに限らず、 400以上のIntegration でライブデータを収集し、即座にダッシュボード化できます。Elasticは自身でも Elastic Cloud / Serverlessプラットフォーム を提供しており、インフラ構築なしに拡張性のある環境をすぐに使い始めることが可能です。 7. まとめ & 次のステップ CSVアップロード → インデックス整形 → 可視化まで、30分で体験可能 Kibana Lensで非エンジニアでも直感的に分析＆共有 AI統合により、非構造データも“意味”で検索・分類が可能に Integrationでライブデータをリアルタイム分析に活用 ElasticのAI Search Platformを活用することで、 検索・分析・可視化・共有がワンストップで完結 します。 💡 Elastic Cloudの無料トライアルもあります。今すぐ体験してみてください！ The post ECサイト購買データを分析！Elasticsearch ＆ Kibana Lens 実践ガイド first appeared on Elastic Portal .

目次 1. 前書き 対象者 できるようになること 前提条件 2. セマンティックリランク 2.1. セマンティックリランクとは？ 2.2. セマンティックリランクの概念図 2.3. セマンティックリランクの方法 2.4. セマンティックリランクのメリットとデメリット 3. Elasticsearch でのセマンティックリランク 3.1. セマンティックリランク利用時のおおまかな手順 3.2. Elasticsearch で利用可能なセマンティックリランカー 3.3. Cohere Rerank v3.5 の APIキーの取得 3.4. リランク用のエンドポイントの作成 3.5. セマンティックリランクを行う検索テンプレートの作成 3.6. 検索の実行 4. セマンティックリランクの応用編 5. サンプルプログラム 6. 参考URL 7. まとめ 1. 前書き 前回に引き続き、ホワイトペーパー「Elasticsearchを使った簡易RAGアプリケーションの作成」に 記載した技術的要素を紹介いたします。(脚注1) 1 今回は、セマンティックリランクです。 なお、セマンティックリランクを行うサンプルプログラムを下記の GitHub リポジトリで公開しています。参考にしてみてください。 blogs/2025-05-semantic-rerank at main · sios-elastic-tech/blogs A sample code for blogs about elasticsearch. Contribute to sios-elastic-tech/blogs development by creating an account on... github.com 対象者 Elastic Cloud のアカウントを持っている人（トライアルライセンスを含む） Elasticsearch の初心者～中級者 できるようになること Elasticsearch で日本語を含むドキュメントのセマンティックリランクを行えるようになる。 前提条件 Elasticsearch （筆者は、Elastic Cloud 8.18.1 Enterprise Edition で動作確認） Elasticsearch で日本語の形態素解析の設定を行っていること（下記で日本語の形態素解析の設定を行っています。） https://elastic.sios.jp/blog/creating-an-index-suitable-for-japanese/ Elasticsearch で日本語のベクトル化の設定を行っていること（下記で日本語のベクトル化の設定を行っています。） https://elastic.sios.jp/blog/preparing-for-vector-search/ Cohere Rerank v3.5（評価用で可） (2025年05月12日時点の情報を元に記載しています。) 2. セマンティックリランク 2.1. セマンティックリランクとは？ キーワード検索のみを行った場合や、ベクトル検索のみを行った場合に適切なドキュメントが検索上位に来ない場合があります。 その改善策として、キーワード検索とベクトル検索のハイブリッド検索を行う方法があります。 しかし、それでもまだクエリーの検索結果として適切なドキュメントが上位に来ない場合もあります。 このような場合の改善策の一つとして、セマンティックリランクがあります。 セマンティックリランクは、いったん取得した検索結果の一覧を、検索クエリーとの関連度順に並び変えるという手法です。 これにより、クエリーの検索結果として適切なドキュメントが上位になることが期待されます。 2.2. セマンティックリランクの概念図 下記の図がセマンティックリランクの処理フローの概念図です。 キーワード検索とベクトル検索のハイブリッド検索後にセマンティックリランクを行う場合の処理フローの概念図 https://elastic.sios.jp/blog/search-using-user-dictionary-registration-in-elasticsearch/ で作成したインデックス（「桃太郎」を改変した「柿之助」を登録したインデックス）に対して、下記の検索クエリーを実行した例を考えます。 検索クエリー = 「柿之助からおむすびをもらったのは誰?」 キーワード検索 + 密ベクトル検索のハイブリッド検索結果（セマンティックリランク前） 順位 検索結果 1 … 2 …ゴリラもおむすびを一つもらって、… 3 …鷹もおむすびを一つもらって、… 4 … 5 …猫はおむすびを一つもらって、… ↓ ハイブリッド検索＋セマンティックリランク （検索結果を「柿之助からおむすびをもらったのは誰?」に関連度が高い順に並び変える） 順位 検索結果 1 …鷹もおむすびを一つもらって、… 2 …ゴリラもおむすびを一つもらって、… 3 …猫はおむすびを一つもらって、… 4 … 5 … 検索クエリーとの関連度が高いものが上位に来るようになります。 2.3. セマンティックリランクの方法 大きく分けると3つの方法があります。 a. cross-encoder model を使って、クエリーのベクトルと、検索対象ドキュメントのベクトルを比較し、近いものを見つける。 b. bi-encoder model を使って、リランク処理を行う。 c. LLMにクエリーと検索対象ドキュメントを渡して、リランクしてもらう。 Elasticsearch では、a. cross-encoder model を利用することができるので、 今回は、a. の cross-encoder model を使う方法を採用します。 2.4. セマンティックリランクのメリットとデメリット セマンティックリランクにはメリットとデメリットがあります。 メリット クエリーとの関連度が高いドキュメントが検索結果の上位に来やすくなる。 デメリット リランク処理を行う分、遅くなる。 リランク処理のためのコストがかかる場合がある。 リランカーに大量にドキュメントを渡してしまうと、その分だけ処理時間が長くなってしまいます。 また、リランカーが受け取れる量には限界があります（あまりにも大量のドキュメントは受け取ることができません）。 かといって、あまりにも少ないドキュメントだけを渡すと、適切なドキュメントがリランク対象から漏れてしまう可能性があります。 何件のドキュメントをリランカーに渡せばよいのか？　は、PoC を行うなどして決めていく必要があります。 3. Elasticsearch でのセマンティックリランク 3.1. セマンティックリランク利用時のおおまかな手順 Semantic reranking | Elastic Docs Re-rankers improve the relevance of results from earlier-stage retrieval mechanisms. Semantic re-rankers use machine lea... www.elastic.co に手順が掲載されています。 引用となりますが、以下の手順が必要です。 1. リランクモデルを選択し、利用可能な状態とする。 2. Elasticsearch 上でリランク用のエンドポイントを作成する。 3. リランク処理を行うリトリーバーを定義する。 3.2. Elasticsearch で利用可能なセマンティックリランカー Elasticsearch v8.18.1 では、いくつかのセマンティックリランカーを利用できます。 Create inference API | Elasticsearch Guide [8.18] | Elastic www.elastic.co 上記の URL からの引用となりますが、下記を利用可能です。 a. AlibabaCloud AI Search の rerank を利用する。 b. Cohere の rerank を利用する。 c. Elasticsearch の rerank を利用する。 d. Google Vertex AI の rerank を利用する。 e. VoyageAI の rerank を利用する。 f. JinaAI の rerank を利用する。 今回は、b. Cohere Rerank v3.5 を利用します（無償での検証が可能なため）。 ※日本語を含むドキュメントをリランクしたい場合、日本語に対応したリランカーを利用する必要があります。Cohere Rerank v3.5 は、日本語に対応しています。 Introducing Rerank 3.5: Precise AI Search Rerank 3.5 delivers improved reasoning and multilingual capabilities to search complex enterprise data with greater accu... cohere.com 3.3. Cohere Rerank v3.5 の APIキーの取得 1. https://cohere.com/ に Sign in します。 2. APIキーを発行します。 発行した APIキー をメモ帳などに保存しておきます。 ※Cohere のWebサイトは時々変更されるので、画面のコピーは掲載していません。 3.4. リランク用のエンドポイントの作成 以下のリクエストを Elastic Cloud の Console から発行します。 PUT _inference/rerank/cohere_rerank_v3pt5 { "service": "cohere", "service_settings": { "api_key": "<CohereのAPI-KEY>", "model_id": "rerank-v3.5", "rate_limit": { "requests_per_minute": 10 } }, "task_settings": { "top_n": 10, "return_documents": true } } <CohereのAPI-Key>には、さきほど取得した Cohere の APIキーを転記します。 Trial Key の利用なので、”requests_per_minute”: 10 としておきます。 Cohere Rerank v3.5 に渡すドキュメント数は、ひとまず、10 としておきます。（”top_n”: 10） 3.5. セマンティックリランクを行う検索テンプレートの作成 RRFによるハイブリッド検索後にセマンティックリランクを行うリトリーバーを検索テンプレートとして定義します。 下記のリクエストを Elastic Cloud の Console から発行します。 PUT _scripts/rrf_search_template_with_rerank { "script": { "lang": "mustache", "source": """{ "_source": false, "fields": [ "chunk_no", "content" ], "size": "{{size}}{{^size}}10{{/size}}", "retriever": { "text_similarity_reranker": { "retriever": { "rrf": { "retrievers": [ { "standard": { "query": { "match": { "content": "{{query_string}}" } } } }, { "standard": { "query": { "semantic": { "field": "content.text_embedding", "query": "{{query_for_vector}}" } } } } ], "rank_window_size": "{{size}}{{^size}}10{{/size}}", "rank_constant": "{{rank_constant}}{{^rank_constant}}20{{/rank_constant}}" } }, "field": "content", "rank_window_size": "{{size}}{{^size}}10{{/size}}", "inference_id": "cohere_rerank_v3pt5", "inference_text": "{{query_for_vector}}" } } {{#highlight}} , "highlight": { "fields": { "content": {} }, "pre_tags": ["<strong>"], "post_tags": ["</strong>"] } {{/highlight}} } """ } } セマンティックリランクを行う上での重要なキーワードは、” text_similarity_reranker ” です。詳細は、Elasticsearch の公式ドキュメントを参照してください。 キーワード検索とベクトル検索のハイブリッド検索の結果上位10件をリランカーに渡しています （ リランク用の特別な実装は必要ありません ）。 3.6. 検索の実行 さきほど作成した検索テンプレートを使って、検索してみます。 リクエスト GET /kakinosuke/_search/template { "id": "rrf_search_template_with_rerank", "params": [ "query_string": "柿之助からおむすびをもらったのは誰?", "query_for_vector": "柿之助からおむすびをもらったのは誰?" ] } レスポンス { ... "hits": [ { ... 鷹もおむすびを一つもらって、柿之助のあとからついて行きました。 ... }, { ... ゴリラもおむすびを一つもらって、あとからついて行きました。 ... }, { ... 猫はおむすびを一つもらって、柿之助のあとから、ついて行きました。 ... }, ... ] } } 質問との関連度が高いドキュメントが上位に来ています。 4. セマンティックリランクの応用編 さきほどはキーワード検索＋密ベクトル検索のハイブリッド検索結果をセマンティックリランクしましたが、 　キーワード検索の上位10件　と　ベクトル検索の上位10件　の計20件（ただし重複分を除く）をセマンティックリランクする といった方法も考えられます。 メリット 本当に見つけたいドキュメントがキーワード検索で上位に来るが、ベクトル検索では上位に来ないような場合に見つけやすくなる。 本当に見つけたいドキュメントがベクトル検索で上位に来るが、キーワード検索では上位に来ないような場合に見つけやすくなる。 デメリット： リランカーに渡す件数が多くなると遅くなる。 リランカーに渡す処理をコーディングする必要がある。 5. サンプルプログラム 下記の GitHub リポジトリでセマンティックリランクを行った検索結果を返すサンプルを公開しています。 blogs/2025-05-semantic-rerank at main · sios-elastic-tech/blogs A sample code for blogs about elasticsearch. Contribute to sios-elastic-tech/blogs development by creating an account on... github.com セマンティックリランクを行うと検索結果の順位が変わります。 セマンティックリランク後に RAG を行うことも可能ですが、このサンプルはドキュメント数が少ないため、セマンティックリランクの有無による RAG での回答の差異は見られませんでした。 （もっと大量のドキュメントがあれば、差異は出てくると思われます。） 6. 参考URL その他の参考URL です。 https://www.elastic.co/guide/en/elasticsearch/reference/current/semantic-reranking.html https://www.elastic.co/guide/en/elasticsearch/reference/current/infer-service-cohere.html https://www.elastic.co/guide/en/elasticsearch/reference/current/retriever.html https://www.elastic.co/guide/en/elasticsearch/reference/current/_retrievers_examples.html#retrievers-examples-text-similarity-reranker-on-top-of-rrf 7. まとめ セマンティックリランクを行うことで、クエリーとの関連度が高いドキュメントが上位に来るようになりました。 （その際、リランカーに上位n件を渡す処理や、リランカーからのリランク結果を受け取るための 特別な実装は必要ありません 。） RAG での検索結果が適切となり、その後の回答の精度の向上につながることもあります。 要件に合わせて、 セマンティックリランクを採用するか否か？ 採用するとすれば、どのリランカーを採用するか？ リランク前の検索をどうするか？ 何件のドキュメントをリランク対象とするか？ などを検討してみてください。 ホワイトペーパー「Elasticsearchを使った簡易RAGアプリケーションの作成」は、下記からダウンロードできます。 （E-mailアドレスなどの入力が必要です。） https://elastic.sios.jp/whitepaper/ ↩︎ The post Elasticsearch でのセマンティックリランク first appeared on Elastic Portal .

最近、Elasticの資格を取得するために自分のMシリーズチップ搭載のMacにElasticsearchとKibanaを直接インストールしてみました。 この記事では、その体験をもとに分かりやすくまとめましたので、ぜひ参考にしてみてください。 目次 ElasticsearchとKibanaってなに？ なぜローカルインストール？ Elasticsearchのインストール手順 Step1：Elasticsearchのダウンロード Step2：ダウンロードファイルを展開 Step3：Elasticsearchを起動 Step4：MacのGatekeeper警告を回避 Step5：動作確認 ログイン情報 Kibanaのインストール手順 Step1：Kibanaのダウンロード Step2：ファイルを展開 Step3：Gatekeeper警告の解除 Step4：Kibanaの起動 Step5：Kibanaの動作確認 まとめ ElasticsearchとKibanaってなに？ Elasticsearch は分散型検索・分析エンジンで、ログ管理やセキュリティ分析、eコマースデータ分析などに使われています。 Kibana はそのデータをダッシュボードやチャートで視覚化するツールです。 両方ともElastic Stackの一部で、無料で使える点が魅力です。 なぜローカルインストール？ コストゼロ ：Elastic Cloudと違って無料 データプライバシー ：外部送信せず学習可能 学習に最適 ：資格取得の練習にぴったり Elasticsearchのインストール手順 Step1：Elasticsearchのダウンロード 公式サイトの Elasticsearchダウンロードページ から最新版をダウンロードします。適切なプラットフォーム（緑のボックス）をプルダウンから選択し、ダウンロードボタン（赤）をクリックします。私はMacbook pro M4なので下のようになります。 Step2：ダウンロードファイルを展開 ダウンロードした elasticsearch-8.17.4-darwin-aarch64.tar.gz をダブルクリックして展開します。 コマンドラインから展開する場合 tar -xzf elasticsearch-8.17.4-darwin-aarch64.tar.gz Step3：Elasticsearchを起動 ターミナルで以下のコマンドを入力して、展開したフォルダに移動します。 cd elasticsearch-8.17.4/ ./bin/elasticsearch Step4：MacのGatekeeper警告を回避 MシリーズMacの場合、起動時にGatekeeper（セキュリティ機能）によってJavaがブロックされることがあります。 ターミナルを開いて以下のコマンドを入力し、制限を解除します： xattr -d com.apple.quarantine /path/to/jdk.app ※/path/to/jdk.appはあなたが展開したElasticsearchフォルダ内のパスに置き換えてください。 この後もMacのセキュリティポップアップが１、２回表示されますがいつも通りに解除します。 ※controller.appにも表示があれば同じ手順で進みます。 システム設定 → プライバシーとセキュリティ → 「このまま開く」をクリック。 管理者パスワードを入力して承認。 Step5：動作確認 ブラウザで http://localhost:9200 にアクセス。 こんな表示があれば 左下をクリックして進みます。 本記事では最新版（8.17.4）を対象としていますが、スクリーンショットは一つ前のバージョンを使用しています。（8.17.4）もほぼ同じです。 表示されれば、無事Elasticsearchのインストール成功です！ ログイン情報   ユーザー名：elastic   パスワード：ターミナルに表示されたJSON形式の文字列内 Kibanaのインストール手順 Step1：Kibanaのダウンロード 公式の Kibanaダウンロードページ から最新版を選択してダウンロードします。「darwin（macOS）」を選択。 Step2：ファイルを展開 ダウンロードした kibana-8.17.4-darwin-aarch64.tar.gz をダブルクリックして展開。 Step3：Gatekeeper警告の解除 Elasticsearchと同様に、ターミナルから以下のコマンドで解除します。 xattr -d com.apple.quarantine /path/to/kibana 解除できない場合は、システム設定で「このまま開く」を選びます。 Step4：Kibanaの起動 ターミナルで展開したフォルダに移動後、起動コマンドを入力。 cd kibana-8.17.4/ ./bin/kibana Step5：Kibanaの動作確認 ブラウザで以下のURLにアクセス。 http://localhost:5601 localhost 注意） 登録トークンはElasticsearch起動後30分以内に使用する必要があるので注意しましょう。 これで、KibanaのインストールとElasticsearchとの連携も完了です！ まとめ 今回、MシリーズMac上でElastic環境をローカルに構築する方法を紹介しました。 無料・安全・手軽に始めたい方におすすめです！ The post MシリーズMacにElasticsearchとKibanaをインストールする手順ガイド first appeared on Elastic Portal .

目次 1. 前書き 対象者 できるようになること 前提条件 2. メタデータ 2.1. メタデータとは？ 2.2 メタデータを考慮しない検索 2.3. メタデータを活用した検索 3. メタデータによるフィルタリングを考慮した検索テンプレート 4. サンプルソース 5. 実行例 5.1. メタデータを使わずに検索した場合 5.2. メタデータを活用して検索した場合 5.3. メタデータを使わずにRAGを行った場合 5.4. メタデータを活用してRAGを行った場合 6. 参考情報 7. まとめ 1. 前書き 前回に引き続き、ホワイトペーパー「Elasticsearchを使った簡易RAGアプリケーションの作成」に 記載した技術的要素を紹介いたします。（*脚注1） 1 今回は、メタデータの活用です。 なお、このブログで使用しているサンプルコードは、下記の GitHub リポジトリで公開しています。 blogs/2025-05-search-with-metadata at main · sios-elastic-tech/blogs A sample code for blogs about elasticsearch. Contribute to sios-elastic-tech/blogs development by creating an account on... github.com 対象者 Elastic Cloud のアカウントを持っている人（トライアルライセンスを含む） Elasticsearch の初心者～中級者 できるようになること Elasticsearch でメタデータを活用した検索を行えるようになる。 前提条件 Elasticsearch を利用できること （筆者は、Elastic Cloud 8.18.1 Enterprise License で確認） Elasticsearch で日本語の形態素解析の設定を行っていること https://elastic.sios.jp/blog/creating-an-index-suitable-for-japanese/ で、日本語の形態素解析の設定を行っています。 LLM を利用できること （筆者は、Cohere および Ollama で確認） なお、今回のサンプルでは、説明を簡素にするためにベクトル検索は行いません。キーワード検索のみ行います。 (2025年05月07日時点の情報を元に記載しています。) 2. メタデータ 2.1. メタデータとは？ このブログ内で「メタデータ」と呼んでいるのは、ドキュメントの ファイル名 ファイルの種類 作成者 作成日 更新日 文書のタイトル 章のタイトル カテゴリー キーワード タグ 要約 想定されるQ&A など、ドキュメントに関する情報のことです。 2.2 メタデータを考慮しない検索 有価証券報告書 | IR（投資家情報）‐サイオス株式会社> サイオス株式会社の有価証券報告書をご覧いただけます。 www.sios.com で公開されているサイオス株式会社の有価証券報告書(PDF)の抜粋を検索する場合を考えます。 （下記に表示している各ブロックが１つのチャンクだとします。） 2018年12月期の有価証券報告書の抜粋 (c) 受注実績 当連結会計年度の受注実績をセグメントごとに示すと、次のとおりであります。 セグメントの名称 受注高(千円) 前年同期比(％) 受注残高(千円) 前年同期比(％) オープンシステム基盤事業 7,413,251 +7.2 1,413,726 +13.8 アプリケーション事業 5,591,926 △4.5 1,324,304 +1.4 合計 13,005,178 +1.8 2,738,031 +7.5 2019年12月期の有価証券報告書の抜粋 (c) 受注実績 当連結会計年度の受注実績をセグメントごとに示すと、次のとおりであります。 セグメントの名称 受注高(千円) 前年同期比(％) 受注残高(千円) 前年同期比(％) オープンシステム基盤事業 7,713,257 +4.0 1,431,537 +1.3 アプリケーション事業 6,175,620 +10.4 1,508,696 +13.9 合計 13,888,877 +6.8 2,940,234 +7.4 2020年12月期の有価証券報告書の抜粋 (c) 受注実績 当連結会計年度の受注実績をセグメントごとに示すと、次のとおりであります。 セグメントの名称 受注高(千円) 前年同期比(％) 受注残高(千円) 前年同期比(％) オープンシステム基盤事業 9,073,642 +17.6 1,621,310 +13.3 アプリケーション事業 6,109,346 △1.1 1,660,413 +10.1 合計 15,182,988 +9.3 3,281,724 +11.6 2021年12月期の有価証券報告書の抜粋 (c) 受注実績 当連結会計年度の受注実績をセグメントごとに示すと、次のとおりであります。 セグメントの名称 受注高(千円) 前年同期比(％) 受注残高(千円) 前年同期比(％) オープンシステム基盤事業 9,691,248 +6.8 1,724,230 +6.3 アプリケーション事業 6,883,678 +12.7 2,407,648 +45.0 合計 16,574,927 +9.2 4,131,879 +25.9 2022年12月期の有価証券報告書の抜粋 (c) 受注実績 当連結会計年度の受注実績をセグメントごとに示すと、次のとおりであります。 セグメントの名称 受注高(千円) 前年同期比(％) 受注残高(千円) 前年同期比(％) オープンシステム基盤事業 8,843,132 △8.8 1,850,417 +7.3 アプリケーション事業 5,772,577 △16.1 2,488,613 +3.4 合計 14,615,709 △11.8 4,339,030 +5.0 2023年12月期の有価証券報告書の抜粋 (c) 受注実績 当連結会計年度の受注実績をセグメントごとに示すと、次のとおりであります。 セグメントの名称 受注高(千円) 前年同期比(％) 受注残高(千円) 前年同期比(％) オープンシステム基盤事業 10,503,935 +18.8 2,444,937 +32.1 アプリケーション事業 5,541,619 △4.0 2,062,760 △17.1 合計 16,045,555 +9.8 4,507,698 +3.9 2024年12月期の有価証券報告書の抜粋 (c) 受注実績 当連結会計年度の受注実績をセグメントごとに示すと、次のとおりであります。 セグメントの名称 受注高(千円) 前年同期比(％) 受注残高(千円) 前年同期比(％) オープンシステム基盤事業 14,871,485 141.6 2,742,583 112.2 アプリケーション事業 6,400,717 115.5 2,477,333 120.1 合計 21,272,202 132.6 5,219,917 115.8 ※なお、上記は、pdfplumber を使って PDF から Markdown 形式で抽出したデータの抜粋です。 これらを、1つのインデックスに登録してみます。 インデックスの作成は省略します。 詳細は、下記の github 内のファイルを参照してください。 https://github.com/sios-elastic-tech/blogs/tree/main/2025-05-search-with-metadata/es_requests/01_create_index_settings.md https://github.com/sios-elastic-tech/blogs/tree/main/2025-05-search-with-metadata/es_requests/02_create_index_mappings_with_meta.md インデックスを作成した後、ドキュメントを登録していきます。 詳細は、下記の github 内のファイルを参照してください。 https://github.com/sios-elastic-tech/blogs/tree/main/2025-05-search-with-metadata/es_requests/03_post_docs.md POST /sios_securities_report/_doc { "meta.fiscal_year": "2018年12月期", "content": """ 当連結会計年度の受注実績をセグメントごとに示すと、次のとおりであります。 | セグメントの名称 | 受注高(千円) | 前年同期比(％) | 受注残高(千円) | 前年同期比(％) | |:--|:--|:--|:--|:--:| | オープンシステム基盤事業 | 7,413,251 | +7.2 | 1,413,726 | +13.8 | | アプリケーション事業 | 5,591,926 | △4.5 | 1,324,304 | +1.4 | | 合計 | 13,005,178 | +1.8 | 2,738,031 | +7.5 | """ } ... POST /sios_securities_report/_refresh ※表の部分は、LLM が回答しやすくなるよう、Markdown 形式で記載します。 ※content フィールドには、何年の情報か？が記載されていません。何年の情報か？は、meta.fiscal_year にのみ保持しています。 ドキュメントを登録後に、次の検索クエリーを投げてみます。 GET /sios_securities_report/_search { "query": { "match": { "content": "2024年12月期 オープンシステム基盤事業 受注高" } } } さて、目的のドキュメント(2024年12月期のオープンシステム基盤事業の受注高を含むドキュメント)が 1位でヒットするでしょうか？ 結果は、 ... | オープンシステム基盤事業 | 7,413,251 | ... ... | オープンシステム基盤事業 | 7,713,257 | ... ... | オープンシステム基盤事業 | 9,073,642 | ... ... | オープンシステム基盤事業 | 9,691,248 | ... ... | オープンシステム基盤事業 | 8,843,132 | ... となりました。これらは、それぞれ以下のドキュメントとなっています。 2018年12月期の受注高を示すドキュメント 2019年12月期の受注高を示すドキュメント 2020年12月期の受注高を示すドキュメント 2021年12月期の受注高を示すドキュメント 2022年12月期の受注高を示すドキュメント 2024年12月期のドキュメントが1位にならず、しかも、 2024年12月期以外のドキュメントが多数ヒットしています。 このような検索結果になった理由は、検索対象フィールドである “content” の中に “2024年12月期” といった情報が含まれていないためです。 このため、目的のドキュメントを見つけることが困難になっています。 2.3. メタデータを活用した検索 検索時に会計年度(fiscal_year)によるフィルタリングを行うようにしてみます。 GET /sios_securities_report/_search { "query": { "bool": { "must": { "match": { "content": "2024年12月期 オープンシステム基盤事業 受注高" } }, "filter": { "term": { "meta.fiscal_year": "2024年12月期" } } } } } 結果 ... | オープンシステム基盤事業 | 14,871,485 | ... ... 2024年12月期の受注高を示すドキュメントのみがヒットしました。 （filter で絞り込んでいるので、当然の結果です。） 3. メタデータによるフィルタリングを考慮した検索テンプレート Python から検索しやすくなるよう、検索テンプレートを登録しておきます。このとき、メタデータによるフィルタリングも行うようにしておきます。 PUT _scripts/search_with_meta_template_202505 { "script": { "lang": "mustache", "source": """{ "_source": false, "fields": [ "meta.fiscal_year", "chunk_no", "content" ], "size": "{{size}}{{^size}}10{{/size}}", "query": { "bool": { "must": [ { "match": { "content": "{{query}}" } } ] {{#fiscal_year}} , "filter": [ { "term": { "meta.fiscal_year": "{{fiscal_year}}" } } ] {{/fiscal_year}} } } } """ } } 4. サンプルソース 下記に、メタデータによるフィルタリングを考慮した RAG のサンプルソースを公開しています。 blogs/2025-05-search-with-metadata at main · sios-elastic-tech/blogs A sample code for blogs about elasticsearch. Contribute to sios-elastic-tech/blogs development by creating an account on... github.com Elasticsearch + Streamlit + LLM による RAG です。（RAGを使わずに検索だけ行うことも可能です。） LLM には、Cohere または Ollama を利用できるようにしています。 Cohere を利用する場合は、Cohere の API Key が必要です。 Ollama を利用する場合は、別途、Ollama および利用するモデルのインストールが必要です。 参考にしてみてください。 5. 実行例 サンプルアプリの実行方法については、下記のリンクを参照してください。 blogs/2025-05-search-with-metadata/README.md at main · sios-elastic-tech/blogs A sample code for blogs about elasticsearch. Contribute to sios-elastic-tech/blogs development by creating an account on... github.com 下記に実行例を表示します。 5.1. メタデータを使わずに検索した場合 「2024年のオープンシステム基盤事業の受注高はいくら?」という検索を行ったにもかかわらず、2024年のドキュメントが上位にヒットしていません。他の年のドキュメントが上位にヒットしてしまっています。これは、検索対象の content フィールドに「年」の情報を保持していないためです。 5.2. メタデータを活用して検索した場合 左側のラジオボタンで、あらかじめ《2024年12月期》を選択してから「2024年のオープンシステム基盤事業の受注高はいくら?」という検索を行った結果です。 事前に会計年度によるフィルタリングを行っているので、2024年12月期のドキュメントのみがヒットしています。 5.3. メタデータを使わずにRAGを行った場合 ※これは、Ollama で、hf.co/mmnga/ELYZA-Shortcut-1.0-Qwen-7B-gguf:Q4_K_M を使って回答させた例です。 検索結果には、2024年以外のドキュメントも含まれており、かつ、返却されたデータには「2024年」というキーワードが含まれていません。そのため、LLM からの回答が 「わかりません。」 となっています。 5.4. メタデータを活用してRAGを行った場合 ※これは、Ollama で、hf.co/mmnga/ELYZA-Shortcut-1.0-Qwen-7B-gguf:Q4_K_M を使って回答させた例です。 左側のラジオボタンで、あらかじめ《2024年12月期》を選択してから「オープンシステム基盤事業の受注高はいくら?」という問い合わせを行った結果です。（クエリーから「2024年の」という文字列を除去していますが、これは、「2024年」という条件をメタデータによるフィルタリングで実施しており、LLMに渡すと単なるノイズになってしまうためです。） 事前に会計年度によるフィルタリングを行っているので、2024年12月期のドキュメントのみが検索結果として返却され、それにもとづいて正しい回答が返却されています。 6. 参考情報 メタデータを使った検索に関する、Elasticsearch 社のブログ（英語） Advanced RAG techniques: Data processing & ingestion - Elasticsearch Labs This blog explores and implements advanced RAG techniques which may increase performance, focusing on data processing & ... www.elastic.co Advanced RAG techniques: Querying & testing a RAG pipeline - Elasticsearch Labs This blog discusses and implements RAG techniques which may increase performance, focusing on querying and testing an ad... www.elastic.co 上記の Elastic Search Labs のブログでは、 キーフレーズ 潜在的な質問 エンティティ を GPT-4o などを使って生成しています。 生成した情報をメタ情報としてドキュメントに付与し、検索時に利用するサンプルが紹介されています。 7. まとめ このように メタデータを活用すると目的のドキュメントを見つけやすくなります 。 検索の手助けになるようなメタデータは、ドキュメントの内容や検索要件によるので 一概にコレとは言えませんが、おおよそ下記のようなものがメタデータとなると思われます。 ファイル名 ファイルの種類 作成者 作成日 更新日 文書のタイトル 章のタイトル カテゴリー キーワード タグ 要約 想定されるQ&A このようなメタデータのうち自分たちの検索に有用と思われるものを保持し、検索時に利用することで目的のドキュメントを見つけやすくなります。 さらに、今回のサンプルアプリのように、検索結果が正確になることで RAG の回答精度が上昇する場合もあります。 要件に合わせて、メタデータを考慮した検索を検討してみてください。 ホワイトペーパー「Elasticsearchを使った簡易RAGアプリケーションの作成」は、下記からダウンロードできます。 （E-mailアドレスなどの入力が必要です。） https://elastic.sios.jp/whitepaper/ ↩︎ The post Elasticsearch でのメタデータを活用した検索 first appeared on Elastic Portal .

目次 1. 前書き 対象者 できるようになること 動作に必要な環境 2. CSVファイルの準備 3. Elasticsearch へのCSVファイルの登録 4. エイリアスの作成 5. 検索用テンプレートの作成 6. 読み取り用 Access Key の生成 7. Elasticsearch Endpoint URL の取得 8. コンテナの実行 8.1. ソースコードのダウンロード 8.2. ファイルの修正 8.3. コンテナのビルド～検索アプリの実行 8.4. 検索アプリの表示 9. 検索処理の概要 10. まとめ 1. 前書き 前回は、N-gram 検索の基礎的な内容について記載しました。 今回は、より実践的なサンプルアプリをご紹介いたします。 なお、今回のサンプルアプリは、下記の GitHub リポジトリで公開しています。 blogs/2025-05-ngram-search-part2 at main · sios-elastic-tech/blogs A sample code for blogs about elasticsearch. Contribute to sios-elastic-tech/blogs development by creating an account on... github.com 対象者 Elasticsearch の初心者～中級者 できるようになること Elasticsearch で N-gram を使ったサンプルアプリを動かせるようになる。 Flask を使った簡単なアプリを動かせるようになる。 動作に必要な環境 Elasticsearch （クラウド版でもオンプレミス版でも可。筆者は、version: 8.18.0 のクラウド版で動作確認しました。） Docker コンテナ を動かせる環境　（筆者は、Windows 版の Rancher Desktop 1.18.2 で動作確認しました。） その他、下記は、自動でダウンロードされます。 Python 3.13 elasticsearch 8.18.1 （Elasticsearch の Python用のクライアント） flask 3.1.0 python-dotenv 1.0.1 （2025年5月1日時点の情報を元に記載しています。） 2. CSVファイルの準備 今回のサンプルアプリでは、医薬品マスタの検索を行います。検索対象となる医薬品マスタを準備します。 2.1. 下記の URL から「医薬品マスター」をダウンロードします。 診療報酬情報提供サービス shinryohoshu.mhlw.go.jp 2.2. y.zip がダウンロードされるので、それを展開します。 2.3. y_20250415.csv というファイルが展開されます（2025-04-15版の場合）。 2.4. y_20250415.csv ファイルを Excel や LibreOffice などで開きます。 2.5. 3列目と5列目のみを残し、それ以外の列を削除します。 2.6. 先頭に行を挿入します。 2.7. 先頭行の値に、”medicine_code”, “medicine_name” をそれぞれ入力します。 2.8. y_20250415_col2.csv という名前で保存します。 2.9. y_20250415_col2.csv ファイルをメモ帳などで開き、UTF-8 で保存します。その際、ファイル名を y_20250415_col2_utf8.csv とします。 なお、上記で作成した y_20250415_col2_utf8.csv ファイルは、下記のリポジトリでも公開しています。 blogs/2025-05-ngram-search-part2/csv at main · sios-elastic-tech/blogs A sample code for blogs about elasticsearch. Contribute to sios-elastic-tech/blogs development by creating an account on... github.com 3. Elasticsearch へのCSVファイルの登録 先ほど作成したCSVファイル（y_20250415_col2_utf8.csv）を、Elasticsearch のインデックスへ登録します。 3.1. Elastic Cloud のログイン画面よりログインします。 （オンプレミス版の場合は、Kibana のログイン画面よりログインします。） 3.2. Elastic Cloud の Deployment 一覧より、CSV を登録したい Deployment を選択します。 （オンプレミス版の場合は、この操作は必要ありません。） 3.3. Elastic Cloud の Home 画面が表示されるので、[Upload a file]をクリックします。 3.4. ファイルのアップロード画面が表示されるので、さきほど作成した y_20250415_col2_utf8.csv ファイルを点線で囲まれたエリアにドラッグ＆ドロップします。 3.5. ファイルアップロードの設定画面が表示されるので、[Override settings] をクリックします。 3.6. Override settings 画面が表示されます。 Number of lines to sample に 20000 を入力します（医薬品マスタが約18000件あるため）。 Has header row にチェックが入っていることを確認します（先頭行をフィールド名とするため）。 その後、右下の [Apply] をクリックします。 3.7. 元の画面に戻るので、[Import] をクリックします。 3.8. Import Data の画面が表示されます。 3.9. Advanced のタブをクリックします。 3.10. Import Data の Advanced タブが表示されます。 次のように入力します。 Index name : medicine_20250415 Create data view : off Index settings : 次の内容を張り付けます。 { "index": { "number_of_shards": 1, "number_of_replicas": 1, "refresh_interval": "5s" }, "analysis": { "char_filter": { "ja_normalizer": { "type": "icu_normalizer", "name": "nfkc", "mode": "compose" } }, "tokenizer": { "ja_ngram_tokenizer": { "type": "ngram", "min_gram": 2, "max_gram": 2, "token_chars": [ "letter", "digit", "punctuation", "symbol" ] } }, "analyzer": { "ja_ngram_index_analyzer": { "type": "custom", "char_filter": [ "ja_normalizer" ], "tokenizer": "ja_ngram_tokenizer", "filter": [ "lowercase" ] } } } } mappings : 次の内容を張り付けます。 { "properties": { "medicine_code": { "type": "long" }, "medicine_name": { "type": "keyword", "fields": { "ngram": { "type": "text", "analyzer": "ja_ngram_index_analyzer", "search_analyzer": "ja_ngram_index_analyzer" } } } } } 3.11. 左下の [Import] をクリックします。 3.12. CSV のインポート処理が行われます（少し時間がかかります）。 3.13. CSV のインポートが完了すると、完了画面が表示されます。 これで、medicine_20250415 インデックスに、医薬品マスタの内容が登録されました。 4. エイリアスの作成 今回は、medicine_20250415 という名前のインデックスにインポートしましたが、医薬品マスタは年に数回更新されます。今後、更新があった場合でも、検索しやすくなるよう、エイリアスを作成しておきます。 Dev Tools から Console を表示し、下記のリクエストを実行します。 POST _aliases { "actions": [ { "add": { "index": "medicine_20250415", "alias": "medicine" } } ] } 5. 検索用テンプレートの作成 今回の医薬品マスタの検索アプリは Python で作成しますが、Python から検索しやすくなるよう、検索用テンプレートを Elasticsearch 側で登録しておきます。 Dev Tools から Console を表示し、下記のリクエストを実行します。 PUT _scripts/search_medicine_with_ngram_202505 { "script": { "lang": "mustache", "source": """{ "_source": false, "fields": [ "medicine_code", "medicine_name" ], "size": "{{size}}{{^size}}10{{/size}}", "query": { "bool": { "must": [ { "match_phrase": { "medicine_name.ngram": "{{search_medicine_name1}}" } } {{#search_medicine_name2}} , { "match_phrase": { "medicine_name.ngram": "{{search_medicine_name2}}" } } {{/search_medicine_name2}} ] } } } """ } } 上記の検索用テンプレートを使った検索例です。 GET /medicine/_search/template { "id": "search_medicine_with_ngram_202505", "params": { "size": 30, "search_medicine_name1": "アス", "search_medicine_name2": "100mg" } } 6. 読み取り用 Access Key の生成 Python から検索処理を呼び出すための Access Key を生成しておきます。 Dev Tools から Console を表示し、下記のリクエストを実行します。 POST /_security/api_key { "name": "medicine_read", "role_descriptors": { "medication_read": { "cluster": ["all"], "indices": [ { "names": ["medicine*"], "privileges": ["read"] } ] } } } 成功すると、エンコードされた Access Key が表示されるので、メモ帳などにコピー＆ペーストしておきます（後で使います）。 7. Elasticsearch Endpoint URL の取得 Python のプログラムからアクセスするための Endpoint URL を取得します。Home 画面に戻り、Elasticsearch の大きいボタンをクリックします。 すると、次のような画面が表示されるので、Elasticsearch の Endpoint が表示されている欄のコピーボタンを押します。 コピーした Endpoint の URL をメモ帳などにペーストしておきます（後で使います）。 8. コンテナの実行 サンプルアプリを実行するための下準備はできたので、いよいよ、サンプルアプリを動かしていきます。 ただし、サンプルアプリの各ソースコードを逐次説明していくと、内容が膨大になるため、今回は要点のみを後述しています。 8.1. ソースコードのダウンロード GitHub のリポジトリからソースコードをダウンロードします。 下記の URL へアクセスします。 GitHub - sios-elastic-tech/blogs: A sample code for blogs about elasticsearch. A sample code for blogs about elasticsearch. Contribute to sios-elastic-tech/blogs development by creating an account on... github.com 画面上部の [<> Code] をクリックし、さらに [Download ZIP] をクリックします。 blogs-main.zip ファイルがダウンロードされるので、この zip ファイルを展開します。 8.2. ファイルの修正 環境に合わせてファイルを修正します。 さきほど展開した blogs-main/ フォルダの下の 2025-05-ngram-search-part2/flask_app/ フォルダへ移動します。 cd blogs-main/2025-05-ngram-search-part2/flask_app .env ファイルを環境に合わせて修正します。 elasticsearch_endpoint='' read_api_key_encoded='' 7. で取得したURL を elasticsearch_endpoint に、 6. で取得した Access Key を read_api_key_encoded に、 それぞれ転記します。 8.3. コンテナのビルド～検索アプリの実行 コンテナをビルドします。 docker compose build コンテナを実行開始します。 docker compose up -d コンテナに接続します。 docker exec -it search_with_ngram_sample_202505 /bin/bash （search_with_ngram_sample_202505 は、コンテナ名です。） 検索アプリを実行します。 python run.py 8.4. 検索アプリの表示 Webブラウザで、localhost:5000 （あるいは、127.0.0.1:5000) にアクセスします。 次のような画面が表示されます。 試しに、検索キーワード1 に “アス” を入力してみます。すると、下部の医薬品リストに、”アス”を含む候補が表示されます（詳細は割愛しますが、2文字以上入力すると検索するようにプログラムしています）。 さらに、検索キーワード2に “10mg” と入力してみます。すると、医薬品リストが、”アス”を含み、かつ、”10mg”を含むものに更新されます。 ここで、検索キーワード2を “100mg” に変更してみます。すると、医薬品リストが “アス” を含み、かつ、”100mg” を含むものに更新されます。 画像だけではわかりにくいと思いますので、下記に動画を添付しています。 これを見て頂ければ、これらの更新が瞬時に行われ、利用者にとってもストレスなく操作できることがおわかりになるかと思います。 document.createElement('video'); https://elastic.sios.jp/wp-content/uploads/2025/05/search_medicine_20250501.mp4 なお、医薬品をクリックすると、選択した医薬品のコードと名称を表示するようにしています（これは、おまけの機能です。N-gram 検索とは直接関係ありません）。 検索アプリの停止用ボタンは用意していないので、停止させたい場合は、Ctrl+C を押すなり、コンテナを停止させるなりしてください。 9. 検索処理の概要 Web ブラウザ上で検索キーワード1 または 2 に、何かのキーが入力されたら（onkeyupのイベントを検知したら）static/js/scripts.js の onkeyup1() または onkeyup2() が呼ばれます。 そこで、前回の入力値との比較を行い、違っていたら、/search_medicine へリクエストを投げます。 app.py の def search() で、検索キーワード1 および 検索キーワード2 を受け取り、検索用パラメータを生成します。Elasticsearch に生成した検索用パラメータを渡し、検索用テンプレートを使って N-gram 検索を行います。検索結果を呼び出し元 (JavaScript) に返します。 static/js/scripts.js で、検索結果を受け取り、画面に反映させます。 10. まとめ N-gram 検索を利用すると、kuromoji が知らない単語でも検索することができます。 医薬品や商品マスタなど、2～3文字を入力すると対象項目を絞り込みたいような場面に適用しやすいことがわかっていただけたかと思います。 The post Elasticsearch での N-gram 検索 (Part 2) 医薬品マスタの検索 first appeared on Elastic Portal .

MCPとは？ から、LLMの能力を最大限引き出す共通ルールMCPをPythonで自作し、Elasticsearchと連携させる具体的な手順を説明します。 目次 LLMは万能じゃない？AI導入の壁 MCP（Model Context Protocol）とは？ なぜ今、MCPが注目されているのか？ MCPエコシステム MCPの仕組みを理解する：シーケンス図で見る処理の流れ 【実践】MCPサーバーをPythonで構築しElasticsearchと連携する手順 前提条件 ステップ１: UVパッケージマネージャーの導入 ステップ２: MCPサーバーの作成 ステップ３: MCPサーバーのコードを書く ステップ４: Claude Desktop アプリのインストール ステップ５: MCP サーバーの起動 ステップ６: Claude Desktopとの連携設定 Claudeの設定 ツールの実行テスト ステップ７: Claudeからの動作確認 トラブルシューティング：困ったときのヒント 最後に LLMは万能じゃない？AI導入の壁 ChatGPTやClaudeなどの大規模言語モデル（LLM）は、私たちの日常業務に革命をもたらしています。しかし、こんな疑問を持ったことはありませんか？ 「メールを送って」と頼んだのに、実際には送ってくれない 検索はできるけど、社内データベースとのやり取りは難しい そう、LLMはテキストを“予測”するだけのモデルに過ぎず、自分で“行動”する力は持っていません。 MCP（Model Context Protocol）とは？ MCPとは、LLMがさまざまな外部ツールと統一的に連携できるようにするための「共通ルール（プロトコル）」です。 ソフトウェア開発の世界では「標準」がとても重要です。たとえば「REST API」は、異なるシステム同士がスムーズに連携できる共通ルールとして広く使われています。 この“標準の考え方”をLLMにも適用したものが、MCPになります。 なぜ今、MCPが注目されているのか？ 従来のようにツールごとにバラバラのAPIを組み合わせる必要はなく、MCPを通すことで 統一された方法 でさまざまなタスクを実行できます。 ツール連携の仕組みがシンプルになり、開発効率が向上 コードの再利用性や保守性がアップ セキュリティの統一管理が可能 LLMを実際の業務・サービスに活用しやすくなる MCPエコシステム MCPエコシステムは以下の要素で構成されています。 MCPクライアント／ホスト: 例：Claude, Wind surf, Cursorなど。 機能：エコシステムのクライアント側、すなわちLLM側となる部分です。 プロトコル: 機能：クライアントとサーバー間の双方向の接続を担います。 場所：MCPクライアントとMCPサーバーの間に存在します。 MCPサーバー: 機能：外部サービス（その機能や実行可能なこと）をクライアントに翻訳して伝えます。 サービス: 機能：LLMがアクセスしたい外部の機能やデータソースそのものです（例：Elastic）。 MCPの仕組みを理解する：シーケンス図で見る処理の流れ MCPを利用したLLMと外部サービスの連携は、以下のシーケンス図のように進行します。 【実践】MCPサーバーをPythonで構築しElasticsearchと連携する手順 ここからは、実際にMCPサーバーを構築し、Elasticsearchと連携する手順を示します。これにより、自然言語を用いたElasticsearchの操作が可能になります。 前提条件 Macbook Pro M4チップ VS code、Python が使える好みのIDE Claude Desktop アプリをインストール済み（今回は無料枠） Elasticsearch 環境 ※ MCPサーバー作成の公式クイックスタートを参考に進みます https://github.com/modelcontextprotocol/python-sdk ステップ１: UVパッケージマネージャーの導入 uvをインストール。 ※ https://docs.astral.sh/uv/getting-started/installation/ curl -LsSf https://astral.sh/uv/install.sh | sh インストール後、以下で確認： which uv /usr/local/bin/uv などが出れば成功です。 ステップ２: MCPサーバーの作成 ターミナルを開き、以下のコマンドで新しいプロジェクト（mcp-elasticsearch）を初期化します。 uv init mcp-elasticsearch 作成されたプロジェクトディレクトリに移動します。 cd mcp-elasticsearch MCP の CLI パッケージをプロジェクトの依存関係に追加します。 uv add "mcp[cli]" これで、MCP Python SDK がインストールされ、プロジェクトの準備が完了しました。 ステップ３: MCPサーバーのコードを書く Python用のMCP公式SDKを参考に進みます。 https://github.com/modelcontextprotocol/python-sdk mcp-elasticsearch プロジェクトを Visual Studio Code で開きます。 env ファイルを作成し、以下を記述。 ELASTIC_USER=elastic ELASTIC_PASSWORD=**** ELASTIC_CLOUD_URL=https://your-deployment.aws.found.io プロジェクトフォルダにあるmain.py の中身を以下のコードに置き換えます。 # ========================================= # Elasticsearch MCP Server for Claude # ========================================= from mcp.server.fastmcp import FastMCP from elasticsearch import Elasticsearch from dotenv import load_dotenv import os # ---------------------- # 🔧 Setup # ---------------------- print("Loading environment variables...") load_dotenv() # Start MCP server mcp = FastMCP("ElasticsearchMCP") # Connect to Elasticsearch try: es = Elasticsearch( os.getenv("ELASTIC_CLOUD_URL"), basic_auth=(os.getenv("ELASTIC_USER"), os.getenv("ELASTIC_PASSWORD")) ) print("🔗 Connected to Elasticsearch!") except Exception as e: print("❌ Failed to connect:", e) es = None # ---------------------- # 🛠️ MCP Tools # ---------------------- @mcp.tool() def list_indices() -> list: """Get all index names in the cluster.""" # ES Query: GET /_cat/indices return list(es.indices.get_alias().keys()) if es else ["ES not initialized"] @mcp.tool() def get_cluster_health() -> dict: """Check the health status of the Elasticsearch cluster.""" # ES Query: GET /_cluster/health return es.cluster.health() if es else {"error": "ES not initialized"} @mcp.tool() def count_documents(index_name: str) -> int: """Count how many documents exist in a given index.""" # ES Query: GET /{index}/_count try: return es.count(index=index_name)['count'] if es else -1 except Exception as e: return f"Error: {str(e)}" @mcp.tool() def search_index(index_name: str, keyword: str) -> list: """Search for documents in an index using a keyword.""" # ES Query: # POST /{index}/_search # { # "query": { "match": { "_all": "keyword" } } # } try: result = es.search( index=index_name, query={"match": {"_all": keyword}}, size=5 ) return [doc["_source"] for doc in result["hits"]["hits"]] except Exception as e: return [f"Error: {str(e)}"] @mcp.tool() def get_index_mapping(index_name: str) -> dict: """Retrieve the field definitions (mappings) of an index.""" # ES Query: GET /{index}/_mapping try: return es.indices.get_mapping(index=index_name)[index_name]["mappings"] except Exception as e: return {"error": str(e)} @mcp.tool() def delete_index(index_name: str) -> str: """Delete an entire index (irreversible).""" # ES Query: DELETE /{index} try: es.indices.delete(index=index_name) return f"✅ Deleted index '{index_name}'" except Exception as e: return f"❌ Error: {str(e)}" @mcp.tool() def get_recent_docs(index_name: str, size: int = 5) -> list: """Fetch the most recent documents from an index.""" # ES Query: # POST /{index}/_search # { # "size": 5, # "sort": [{ "@timestamp": "desc" }] # } try: result = es.search( index=index_name, size=size, sort=[{"@timestamp": "desc"}] ) return [doc["_source"] for doc in result["hits"]["hits"]] except Exception as e: return [f"Error: {str(e)}"] # ---------------------- # Start MCP Server # ---------------------- if __name__ == "__main__": print("🚀 Starting MCP server...") if os.environ.get("RUN_MCP_MANUALLY"): print("Running in manual mode (not Claude Desktop).") else: print("Waiting for Claude Desktop input (stdio mode).") try: mcp.run() print("✅ MCP server exited cleanly.") except Exception as e: print("❌ MCP server crashed:", e)  このコードでは、 fast_mcp モジュールから FastMCP クラスをインポートしています。 ElasticsearchMCP という名前で MCP サーバーのインスタンスを作成しています。 @mcp.tool() デコレータを使って、七つの ツールを定義しています。ツールの説明（”””ここに入っている文章 “””）は AI がツールの中身を理解するために重要です。 list_indices() 　　　　　　　　インデックス一覧の取得 get_cluster_health() 　　　　　クラスタの状態確認 count_documents(index) 　　　　ドキュメント件数のカウント search_index(index, keyword)　キーワード検索 get_index_mapping(index) 　　　 マッピング取得 delete_index(index) 　　　　　 インデックス削除 get_recent_docs(index, size)　 最新のドキュメント取得 ステップ４: Claude Desktop アプリのインストール まだインストールしていない場合は、 Claude の公式サイトから Claude Desktop アプリをダウンロードしてインストールしてください。 ※Claude Desktop Download: https://claude.ai/download MCPサーバーと連携させる前の画面↓ ステップ５: MCP サーバーの起動 ターミナルで、mcp-elasticsearch ディレクトリにいることを確認します。 以下のコマンドを実行して、MCP サーバーを起動します。 uv run mcp install main.py サーバー追加されたメッセージを確認できます。 Claudeに設定項目が追加されました。Claude Desktopアプリを開いている場合は、一度終了し、20秒後に再度起動するとMCPサーバーが画面に表示されるようになります。問題が生じた際は、トラブルシューティングのセッションをご確認ください。 ステップ６: Claude Desktopとの連携設定 Claude Desktop アプリで、MCP サーバーが正しく認識されているか確認します。 Claudeの設定 Claude Desktop アプリを開きます。 「Claude」>「設定」>「開発者」に進みます。 「構成を編集」をクリックし、設定ファイル ディレクトリが開きます。(claude-desktop-configuration.json) を好きなIDEで開きます。 設定ファイル内に、以下のような MCP サーバーの設定が記述されているか確認します。 { "mcpServers": { "ElasticsearchMCP": { "command": "/Users/sam-koyama/.local/bin/uv", "args": [ "--directory", "/Users/sam-koyama/MCP/second/mcp-elasticsearch", "run", "main.py" ], "env": { "ELASTIC_USER": "elastic", "ELASTIC_PASSWORD": "3fik3ua3kXnbOlp0ThX41be1", "ELASTIC_CLOUD_URL": "https://my-deployment-a17327.es.ap-northeast-1.aws.found.io" } } } } 違う場合、トラブルシューティングの項を参照してください。 ツールの実行テスト 作成したツールを実際に Claude から実行してみましょう。 Claude Desktop アプリを開始します。 チャットウィンドウ下部に表示されているハンマーアイコン（利用可能な MCP ツールを示します）をクリックします。 先ほど作成したMCPから添付ツール（プラグのアイコン）を選択すると、「連携サービス選択」で追加したプロジェクトが確認できます。 ステップ７: Claudeからの動作確認 Claudeのチャットウィンドウで下記の様なクエリーを投げます。 「 blogsインデックスにあるドキュメントの数を教えて 」 初回利用時には、アクセス許可を求められることがあるので、「Allow for this chat」を選択します。 その前に正解をKibanaのコンソールで確認しましょう。 ということで、応答は「７つ」であれば、MCP サーバーと Claude の連携は成功です！ トラブルシューティング：困ったときのヒント もし MCP サーバーが Claude Desktop に表示されない、またはエラーが表示された場合は、以下の点を確認してみてください。 設定ファイルのパス確認: claude-desktop-configuration.json 内の command フィールドが、UV の絶対パス（例: /usr/local/bin/uv）になっているか確認してください。修正後はファイルを保存し、 Claude Desktop を再起動します。 Claude Desktop の再起動: アプリを一度完全に終了し、再起動してみてください。 デスクトップフォルダへのアクセス許可: Claude Desktop がデスクトップフォルダへのアクセスを求めてきた場合は、必ず許可してください。 最後に 今回は、MCPの基本動作確認のため、Elasticsearch連携のシンプルなコードを使用しました。 現状のMCPには、サーバーセットアップの手作業やローカル設定の煩雑さといった技術的課題が見られますが、新しい技術であるため今後の発展が期待されます。 The post 自然言語でElasticsearchを操作！Python×Claude Desktop×MCP連携例 first appeared on Elastic Portal .