ファイルサーバー等の検索システム構築において、事前に必要なストレージ容量を試算する際の手順を解説します。 今回は、FSCrawler (*1) を使って検索用ストレージサイズの概算見積りを行ってみたいと思います。 (*1) Elastic の正式な製品ではありませんが、ファイルを検索できるよう Elasticsearch に登録してくれるオープンソースです。 目次 1. 検証の概要 2. 環境 3. FSCrawler の初期化と設定 4. 検索用ファイルの配置 5. FSCrawlerの実行 6. 登録

Logstash の転送先や Python 等のアプリケーションから指定する Elasticsearch の接続先 URL（endpoint URL）は、運用形態（Self-Managed、Elastic Cloud Hosted、Elastic Cloud Serverless）ごとに取得方法や基本形式が異なります。 この記事では、それぞれの運用形態における接続先 URL の取得・確認手順をまとめて解説します。 目次 Self-Managed の場合 URLの基本形式 取得・確認手順 Elastic C

Kibanaの表示言語はこれまでサーバー単位の設定（ kibana.yml ）によって一括で決定されていましたが、 Kibana 9.5 からは  ユーザーごとに個別の表示言語を設定できる機能  がベータ版（Beta）として導入されました。 これにより、グローバルなチームや多言語環境でKibanaを運用している場合でも、各ユーザーが好みの言語でダッシュボードやUIを閲覧できるようになります。 本記事では、この表示言語の切り替え機能の概要と具体的な設定手順を解説します。 目次 検証環境

はじめに なぜ移行したか アーキテクチャ 進め方 運用とコストの現実 ハマりどころ Terraform プロバイダのバグ カスタムパッケージの Content-Type tar コマンドの実装差 自動スナップショットと運用タスクの競合 おわりに はじめに 弊社の検索基盤は、長らく EC2 上でセルフホストした Elasticsearch 7.x で動いていました。 これを AWS マネージドの OpenSearch Service に無停止で移行するプロジェクトが、2025年10月から2026年6月にかけ

はじめに こんにちは、AIテクノロジーグループの検索チームです。 昨年公開した エニグモのAI活用を支える「AIテクノロジーグループ」について紹介します！ では、グループ全体の体制と各チームの役割を紹介しました。 本記事ではそのなかの検索チームに焦点を当て、日々どんなシステムを運用し、どんな案件を進めているかをもう一段詳しくお伝えします。 検索チームは名前のとおり BUYMA の検索システムを担当していますが、それだけではありません。 データサイエンティストが開発したモデルを安定して動かす MLOps と

Elastic Clous Serverless では、これまで Amazon Web Services の 東京リージョンを利用することができましたが、これに加えて、Google Cloud Platform (GCP) の東京リージョン（ asia-northeast1 ）も利用できるようになりました。 日本国内のワークロードにおいて、インフラ管理不要な検索・分析基盤を低レイテンシーで導入できるようになります。 目次 今回のアップデートのポイント 主な活用ユースケース はじめる手順 参考URL 今回の

Elastic 9.5では、ログの保存方法、ベクトル検索、マルチモーダル検索、AIエージェントの運用、Prometheusからの移行など、幅広い領域に新機能が追加されました。 今回のポイントは、単に機能が増えたことではありません。これまでエンジニアが手作業で行っていた 保存方式の最適化、ベクトル検索の設定、PromQLの書き換え、AIエージェントの調査 を、Elastic側がより多く引き受ける方向へ進んだことです。 この記事では、Elastic 9.5の主要機能について、次の4点に絞って説明します。 何を

Elastic Stack（ELKスタック）を導入する際、多くのエンジニアが最初に頭を悩ませるのが「データの収集・加工（前処理）に何を使うか」という問題です。 かつては「前処理といえばLogstash」の一択でしたが、Elasticsearchに  Ingest Pipeline  が実装されて以降、その手軽さとパフォーマンスから強力な選択肢となっています。 本記事では、LogstashとIngest Pipelineのアーキテクチャの違い、機能面での優劣、そして「結局どちらを選ぶべき

はじめに 本記事は、2026年3月10日に開催された Elastic{ON} Tokyo での発表「 『定型』を許さない製造業データへの挑戦 」の内容をもとにした連載の最終回です。 第1回：ビジュアル情報を活かす 第2回：分断されたデータを繋ぐ 第3回（本記事）：止めずに進化させる 第1回ではビジュアル情報を使った類似図面検索、第2回ではデータソース横断検索の設計について書きました。最終回の本記事では、製造業データの「非定型性」にどう向き合っているか、そして進化し続けるインデックスをどうやって無停止で運用

Elasticsearchのデータ移行やバックアップを、スナップショット機能を使わずに「もっと手軽に、インデックス単位でサクッと行いたい」と思ったことはありませんか？ そんなエンジニアの強い味方になるのが、オープンソースのCLIツール  elasticsearch-dump  （通称：elasticdump）です。 今回は、このツールの基本的な使い方から、実務で役立つ一歩進んだテクニックまでを解説します。 Elasticsearch を運用していると、以下のようなシーンに直面することがよくあります。 開発

注意 本記事は、実際のSplunk本番環境を使った移行試験ではありません。Splunkのsaved searchエクスポートを想定したダミーJSONを使い、Automatic Migrationの仕組み、操作、結果の読み方を確認した検証です。 目次 はじめに 最初に知っておきたい用語 LLM ELSER ES|QLとEQL Splunk saved search Splunk CIMとElastic ECS 必要条件と検証環境 必要条件 Match to Elastic prebuilt rules」をO

はじめに 本記事は、2026年3月10日に開催された Elastic{ON} Tokyo での発表「 『定型』を許さない製造業データへの挑戦 」の内容をもとにした連載の第2回です。 第1回：ビジュアル情報を活かす 第2回（本記事）：分断されたデータを繋ぐ 第3回：止めずに進化させる 前回は、製造業の検索に「ビジュアル」が外せないこと、Elasticsearch の kNN 検索を使った類似図面検索について書きました。 今回は、次に立ちはだかる「データ規模と結合」の壁について掘り下げます。複数のデータソース

はじめに 本記事は、2026年3月10日に開催された Elastic{ON} Tokyo での発表「 『定型』を許さない製造業データへの挑戦 」の内容をもとに、3本の連載記事として再構成したものです。 第1回（本記事）：ビジュアル情報を活かす 第2回：分断されたデータを繋ぐ 第3回：止めずに進化させる キャディ株式会社で、AIデータプラットフォーム「CADDi Drawer」の検索基盤の技術戦略と開発チームのマネジメントを担当している橋本です。 この記事では、製造業の検索で「ビジュアル情報」がなぜ外せない

はじめに 私たちはスピーダ事業のプロダクトチームで企業の検索システムを開発しているチームです。このシステムは単純な企業名などでのキーワード検索にとどまらず、企業の特色といった文章そのものを検索できることを目指しており、基盤には Elasticsearch を採用しています。 こうした「意味で探す」検索を支えているのがベクトル検索です。しかし、すべてのベクトルとの距離をまじめに計算する全探索は、実用的な規模になると現実的ではありません。そこで必要になるのが、賢く候補を絞って高速に近いものを探す ANN（近似

1年ほど前に、日本語アナライザーを比較する記事を書きました。 前回の記事： 日本語アナライザーの比較（Kuromoji / Sudachi / MeCab / LLM の性能検証） あれから1年がたち、日本語の検索まわりは少しずつ変わりました。 新しい選択肢も出てきましたし、考え方も少し変わりました。 そこで今回は、続編としてもう一度比較します。 ただし、前回とまったく同じことを繰り返すわけではなく、 2026年の今なら、こう測るともっと良い、というやり方で見直します。 今回の検証は「去年と同じ条件での定