はじめに こんにちは、タイミーのプラットフォームエンジニアリングチームに所属している徳富( @yannKazu1 )です。 この記事では、スキマバイトサービス「タイミー」のバックエンド（Rails API）に Datadog Test Impact Analysis（TIA） を導入し、PRごとのCIフィードバックを大幅に高速化した取り組みについて紹介します。 なお、バックエンドはRailsアプリケーションなので、テストフレームワークは RSpec を前提として話を進めます。 サービスが成長してプロダクトの機能が増えてくると、テストも当然増えていきますよね。開発者が増えればPRの数も増え、CIの待ち時間がボトルネックになってくるのも、割とあるあるな課題だと思います。同じような悩みを抱えているチームの参考になれば嬉しいです。 背景：膨れ上がるテストとの戦い タイミーのバックエンドはモジュラーモノリスを採用しており、複数のインターフェースを1つのRailsアプリケーションで提供しています。 担当するバックエンドエンジニアの数もかなり多く、当然テストの数もそれに比例して増えていきます。 テスト数は約35,000。そして月に約2,000テストのペースで増加していました。 さらに最近はAIコーディングツールの活用も進み、テストが増えるペースが加速しています。人手に加えてAIコーディングツールの活用も進む中で、テストの増加速度が既存のチューニングでは吸収しきれない状況になりつつありました。 これまでの高速化の取り組み もちろん手をこまねいていたわけではありません。たとえば、 self-hosted runnerの活用 、GitHub Actionsのjobの 35並列 分割、 split-test による実行時間ベースの均等分割、ジョブ内のステップ並列実行（Redis/ESの起動とRuby/bundleセットアップをbackground + wait-allで同時進行）、 MySQLマイグレーションキャッシュ 、Dockerイメージキャッシュなど——泥臭いチューニングを積み重ねてきました。その結果、35,000テストを 約10分 で完走させるところまで持っていくことができました。 しかし、毎月2,000テストずつ増えていく状況では、並列数を増やし続けるのにも限界があります。ノード数を増やせばその分CIコストも増えていきますし、どこかで別のアプローチが必要になるのは明らかでした。 今後の成長を考えると、 すべてのPRですべてのテストを実行するのは持続可能ではない と判断しました。 Datadog Test Impact Analysis（TIA）という選択肢 そこで目をつけたのが Datadog Test Impact Analysis（TIA） です。 TIAは、コード変更の差分を解析し、その変更に関係のあるテストだけを選択的に実行する仕組みです。Datadogが各テストのコードカバレッジを収集・保持しており、「このファイルを変更したなら、このテストを実行すべき」という判断を自動で行ってくれます。 これにより、PRごとのCIでは 変更に関連するテストだけ を実行してフィードバックを高速化しつつ、品質の担保は別の仕組みで行うという戦略が取れるようになります。 TIAを使うための前提条件 TIAを使うには、まず Test Optimization を導入しておく必要があります。Test Optimizationはテスト結果やパフォーマンスデータをDatadogに送信して可視化する仕組みで、TIAはその上に乗っかる機能です。 具体的には以下が必要になります。 Test Optimization の設定が完了していること : datadog-ci gem（ >= 1.0 ）を導入し、CIからテスト結果をDatadogに送信できる状態にしておく Datadog側でTIAを有効化すること : Test Service Settingsページから、 Intelligent Test Runner Activation 権限を持つユーザーがTIAを有効にする必要がある 弊社ではもともとTest Optimizationを使ってテストの実行結果をDatadogで可視化していたので、TIAの導入自体はその延長線上でスムーズに進められました。 設計方針：GitHub Flow + マージキューを活かす ここからが今回のキモです。 弊社は基本的に GitHub Flow を採用しています。mainにマージされるとリリースが走るというシンプルな方針です。そして、mainへのマージには マージキュー（Merge Queue） を利用しています。マージキューの導入については、 こちらの記事 で詳しく紹介しています。 全体のフローはこんな感じです。 flowchart TD A["featureブランチで開発・push"] --> B["PR CI（ci_branch）<br/>TIA有効 → 関連テストのみ実行<br/>⚡ 高速フィードバック"] B -->|CI通過| C["レビュー & Approve"] C --> D["マージキューに投入"] D --> E["マージキュー CI（ci）<br/>全テスト実行<br/>+ Datadogカバレッジ収集"] E -->|全テスト通過| F["mainにマージ"] F --> G["リリース"] style B fill:#e8f5e9,stroke:#4caf50 style E fill:#fff3e0,stroke:#ff9800 ポイントは、 PRのCIとマージキューのCIで役割を分けている ところです。この「マージキュー」の特性をうまく活かすことで、以下のような構成を実現しました。 PRブランチ（ ci_branch ワークフロー） TIAを有効化 して、差分に関連するテストのみを実行 開発者へのフィードバックを高速化 # ci_branch.yml jobs : ci : uses : ./.github/workflows/_ci.yml with : skip : false itr_enabled : true # TIAによるテストフィルタリングを有効化 secrets : inherit マージキュー（ ci ワークフロー merge_group イベント） 全テストを実行 （TIAフィルタリングは無効） Datadogへのカバレッジ収集も同時に実施 これを通過しないとmainにマージされない # ci.yml on : merge_group : jobs : ci : uses : ./.github/workflows/_ci.yml with : skip : ${{ github.event_name != 'merge_group' }} # マージキューでは全テストを実行しつつカバレッジを収集 dd_coverage_enabled : true tia_test_skipping_mode : suite tia_force_run_all : true # gem側のスキップも無効化して全spec実行 secrets : inherit （コード内の tia_test_skipping_mode: suite は、テストの選定を「テストファイル単位」で行う設定です。なぜ suite にしたのかは、後述の「suiteモードを選んだ理由」で詳しく触れます。） つまり、 PRでは「速さ」を、マージキューでは「安全」を という役割分担です。 マージキューのテストを全件パスしないとmainにマージされず、mainにマージされないとリリースされない。この構造があるからこそ、PRのテストを絞っても品質を担保できるわけです。 カバレッジ収集はマージキューで TIAの精度を保つには、カバレッジデータを最新に保つ必要があります。 マージキューは mainにマージされる直前のコミットで全テストを実行 するので、ここでカバレッジを収集すれば常に最新の状態が保たれます。 # ci.yml（merge_group イベント時） dd_coverage_enabled : true # カバレッジ収集を有効化 tia_test_skipping_mode : suite # suite単位で収集 tia_force_run_all : true # gem側のスキップも無効化して全spec実行 当初はこのカバレッジ収集を別ワークフロー（Coverage Build）でも回していたのですが、マージキューで毎回「全テスト実行＋カバレッジ収集」を行う構成にしたことで一本化でき、運用がシンプルになりました。 ddtest plan によるテスト選定と分割の工夫 ddtest plan の基本 TIAによるテスト選定には、Datadogが提供する ddtest CLIツールを使っています。 ./ddtest plan \ --platform ruby \ --framework rspec \ --min-parallelism 1 \ --max-parallelism 1 \ --test-skipping-mode suite \ --tests-location "**/*_spec.rb" \ --tests-exclude-pattern "vendor/**" ddtest plan はDatadog APIと通信して、現在のコミットの差分に対してスキップ可能なテストを判定し、実行すべきテストファイルの一覧を .testoptimization/runner/test-files.txt に出力します。 gem の環境変数スキップではなく ddtest plan を採用した理由 実は ddtest コマンドを使わなくても、datadog-ci gemを導入していれば、環境変数 DD_CIVISIBILITY_ITR_ENABLED=true の設定だけでTIAによるテストスキップを有効にできます。最も手軽な方法です。 ただ、弊社ではこの方法を採用しませんでした。理由は 35並列との相性が悪い からです。 gemの組み込みスキップは、RSpecの実行時に各テストケースを個別にスキップします。そのため、35ノードにテストを分割した後に各ノード内でスキップが走るので、「このノードは割り当てられたテストの大半がスキップされて30秒で終わったけど、別のノードは全部実行対象で5分かかった」といったことが起きます。結果としてノード間のばらつきが大きくなり、並列化の効率がガクッと落ちるんですよね。 そこで、テストの選定は ddtest plan で 実行前に 行い、選定されたファイルだけを split-test で均等に分割する、という方式を取りました。スキップの判断をRSpec実行の外に出すことで、各ノードに割り当てるテスト量を事前にコントロールできるようにしています。 ちなみに ddtest plan 自体にも --min-parallelism / --max-parallelism オプションによるノード分割機能があります。ただ、検証してみたところ split-test と比べてノード間の実行時間のばらつきが大きかったため、分割は引き続き split-test に任せる構成にしました。 ddtest plan は「どのテストを実行するか」の選定だけに使い、「どう分割するか」は split-test に委ねる、という役割分担です。 カバレッジ収集時の罠と DD_TIA_FORCE_RUN_ALL もう一つ、 DD_CIVISIBILITY_ITR_ENABLED 周りで地味にハマったポイントがあります。 TIAが正しくテストを選定するには、各テストがどのソースコードを通過するかという カバレッジデータ をDatadogに送る必要があります。カバレッジ収集は DD_CIVISIBILITY_ITR_ENABLED=true で有効化できます。ただし、この環境変数を true にすると、 カバレッジ収集と同時にテストのスキップも有効になります 。 つまり、カバレッジを集めたいだけなのに、TIAが「このテストはスキップしてOK」と判断したテストのカバレッジが収集できないという矛盾が起きます。これだとカバレッジデータに穴が空き、次回以降のTIA判定精度が落ちていきます。 この問題を解決するために、 datadog-ci gem が提供する datadog_itr_unskippable というRSpecメタデータを活用しています。 datadog-ci gem は、 DD_CIVISIBILITY_ITR_ENABLED=true のときにDatadog APIからスキップ可能なテストの一覧を取得し、該当するテストをスキップします。しかし、RSpecのメタデータに datadog_itr_unskippable: true が設定されているテストは、スキップ対象から除外されて必ず実行されます。 これを利用して、 spec_helper.rb で以下のように 全テストにunskippableメタデータを付与 しています。 # spec_helper.rb if ENV [ ' DD_TIA_FORCE_RUN_ALL ' ] == ' true ' # DD_CIVISIBILITY_ITR_ENABLED はカバレッジ収集と suite スキップを同時に有効化するため、 # 収集専用ジョブでは全 example を unskippable にして forced run させる RSpec .configure do |config| config.define_derived_metadata do |metadata| metadata[ :datadog_itr_unskippable ] = true end end end define_derived_metadata はRSpecの機能で、全テストのメタデータにデフォルト値を追加できます。これにより、gem側のスキップ判定が働いても「このテストはスキップ不可」と判定されるので、結果的に全テストが実行されます。 # マージキューでの環境変数設定 DD_CIVISIBILITY_ITR_ENABLED : true # カバレッジ収集を有効化 DD_TIA_FORCE_RUN_ALL : true # 全テストをunskippableにして必ず実行 DD_CIVISIBILITY_ITR_ENABLED=true でカバレッジ収集の仕組みを有効にしつつ、 DD_TIA_FORCE_RUN_ALL=true で全テストにunskippableメタデータを付与してスキップを防ぐ。これにより、全テストを実行して完全なカバレッジデータを収集できるようになります。 マージキューではこの組み合わせを使い、PRブランチでは DD_CIVISIBILITY_ITR_ENABLED=false （カバレッジ収集もスキップも無効）にして余計なオーバーヘッドを排除しています。 suiteモードを選んだ理由 TIAには testモード と suiteモード の2つの粒度があります。 testモード : 個々のテストケース（ it ブロック）単位でスキップを判定 suiteモード : テストファイル（ _spec.rb ）単位でスキップを判定 今回は suiteモード を採用しました。 理由はシンプルで、 testモードでは35,000テストの分割判定に約2分かかるため です。差分が小さいPRなら問題ありません。しかし全テストに影響する変更（例えば spec_helper.rb の変更など）をした場合は、2分かけて「全テスト実行」という結論になり、かえってオーバーヘッドが大きくなってしまいます。その点、suiteモードなら対象がファイル単位なので、この判定が高速(5s程度)に完了します。 split-test との組み合わせ 前述の通り ddtest plan で選定したファイルを split-test で均等分割するのですが、ここが地味に苦労したポイントです。 split-test はファイルリストを直接受け取れず --tests-glob しか受け付けません。そこで、以下のようにシンボリックリンクを使ってglobのマッチ対象をTIA対象ファイルだけに制限するアプローチを取りました。 # TIA対象ファイルのシンボリックリンクを一時ディレクトリに作成 SPLIT_DIR=$(mktemp -d) while IFS= read -r f; do [ -f "$f" ] && mkdir -p "$SPLIT_DIR/$(dirname "$f")" && ln -s "$WORKSPACE/$f" "$SPLIT_DIR/$f" done < .testoptimization/runner/test-files.txt # 一時ディレクトリ内で split-test を実行（TIA対象のみが均等に分割される） (cd "$SPLIT_DIR" && "$WORKSPACE/split-test" \ --junit-xml-report-dir "$WORKSPACE/tmp/rspec_junit" \ --node-index $NODE_INDEX \ --node-total 35 \ --tests-glob "spec/**/*_spec.rb" \ --tests-glob "packs/*/spec/**/*_spec.rb") ちょっとトリッキーですが、これにより TIAで絞り込んだテストを、実行時間ベースで均等に35分割する ことが実現できました。 なお、35並列のうちTIAの絞り込みで対象テストがゼロになるノードも出てきます。その場合は空のダミーJUnitレポートを出力しておき、後続のジョブが正常に動くようにしています。 PRの全変更を正しく評価するための工夫 もう一つ、導入時にハマったポイントがあります。 ddtest はHEADコミットのdiffだけを見てテスト選定を行います。PRに複数コミットがある場合、最後のコミットの変更しか考慮されません。これだと初期コミットで変更したファイルに関連するテストがスキップされてしまう可能性があります。 そこで、GitHub APIで merge-base（分岐点） を取得し、PRの全変更を1つのdiffとして ddtest に認識させる仕組みを入れています。 # PRの分岐点を取得 MERGE_BASE=$(gh api "repos/$GITHUB_REPOSITORY/compare/main...$GITHUB_SHA" \ --jq '.merge_base_commit.sha') # 分岐点を親、現在のツリーを内容とするコミットを作成 git fetch --depth=1 origin "$MERGE_BASE" --no-tags TREE=$(git rev-parse "HEAD^{tree}") TIA_COMMIT=$(git commit-tree "$TREE" -p "$MERGE_BASE" -m "TIA: all PR changes") git reset --soft "$TIA_COMMIT" これにより、HEADのdiffが「PR全体の変更」を表すようになり、TIAが正しく全変更を評価できるようになります。 全体のアーキテクチャまとめ 最終的な構成を図にすると以下のようになります。 flowchart TD A[開発者がPRを作成] --> B subgraph PR["ci_branch ワークフロー（PRブランチ）"] B["ddtest plan (TIA)\n関連テストのみ抽出"] --> C["split-test\n35並列に均等分割"] --> D["RSpec実行\n（関連テストのみ）"] end D -->|テスト通過| E[マージキューに投入] E --> F subgraph MQ["ci ワークフロー（merge_group イベント）"] F["全テスト実行\n（TIAフィルタリングなし）"] --> G["Datadogカバレッジ収集\n（TIA精度を維持）"] end G -->|全テスト通過| H["mainにマージ → リリース"] style PR fill:#e8f5e9,stroke:#4caf50 style MQ fill:#fff3e0,stroke:#ff9800 導入時のハマりポイントまとめ 実際に導入してみて、いくつかハマったポイントをまとめておきます。 1. testモードの分割コスト 前述の通り、testモードでは35,000テストの分割判定に約2分かかります。suiteモードなら数秒で完了します。テスト数が多い場合はsuiteモード一択だと思います。 2. split-test との組み合わせ split-test がファイルリストを直接受け取れないため、シンボリックリンクを使った一時ディレクトリ方式を採用しました。ちょっとトリッキーですが、確実に動きます。 3. マルチコミットPRの差分評価 ddtest がHEADコミットのdiffしか見ない問題は、merge-baseからのコミットを作り直すことで解決しました。 4. カバレッジの鮮度 TIAの精度はカバレッジデータの鮮度に依存します。当初は別ワークフロー（Coverage Build）でも収集していましたが、マージキューで毎回全テスト+カバレッジ収集を行う構成にしたことで一本化でき、シンプルになりました。 5. TIAで全テストがスキップされるノードの対策 35並列のうち、TIAで対象テストがゼロになるノードが出てきます。その場合はダミーのJUnitレポートを出力して後続のジョブが正常に動くようにしています。 成果 TIA導入前は、PRのCIで全テストを実行していたため 約10分 かかっていました。TIA導入後は変更の差分によって実行されるテスト数が変わりますが、差分が小さいPRでは 1〜2分 で完了するケースもあり、大幅に高速化しています。 おわりに Datadog TIAの導入により、PRごとのテスト実行時間を大幅に短縮しつつ、マージキューで全テストを実行するという安全な構成を実現できました。 ポイントをまとめると： PRブランチ : TIAで関連テストのみ実行 → 高速フィードバック マージキュー : 全テスト実行 + カバレッジ収集 → 品質担保 suiteモード : テスト数が多い場合はtestモードよりsuiteモードが実用的 ddtest plan + split-test : TIAフィルタリングと均等分割の組み合わせがキモ GitHub Flow + マージキュー : この組み合わせがTIA導入の前提条件として非常にフィットした テスト数がどんどん増えていく中で、「全部回す」から「必要なものだけ回す」へのシフトは避けて通れない道だと思います。同じような課題を抱えているチームの参考になれば幸いです。

Elastic 9.5では、ログの保存方法、ベクトル検索、マルチモーダル検索、AIエージェントの運用、Prometheusからの移行など、幅広い領域に新機能が追加されました。 今回のポイントは、単に機能が増えたことではありません。これまでエンジニアが手作業で行っていた 保存方式の最適化、ベクトル検索の設定、PromQLの書き換え、AIエージェントの調査 を、Elastic側がより多く引き受ける方向へ進んだことです。 この記事では、Elastic 9.5の主要機能について、次の4点に絞って説明します。 何を解決する機能なのか 9.5で何が変わったのか どのような人や環境に役立つのか 導入前に何を注意すべきか 対象バージョン ：Elastic 9.5（2026年8月4日リリース） 想定読者 ：Elasticを利用しているエンジニア、導入を検討しているアーキテクト、運用担当者 目次 まず押さえたいGAとTech Preview Columnar Mode：ログを「検索中心」から「分析中心」へ 何を解決する機能か 9.5で何が変わったか なぜ役立つのか 注意点 VectorDB index modeとAuto-calibration：ベクトル検索の初期設定を簡単にする 何を解決する機能か VectorDB index mode DiskBBQとAuto-calibration 注意点 マルチモーダルsemanticフィールド：画像やPDFも意味で検索する 何を解決する機能か 9.5で何が変わったか 注意点 Agent Builder tracing：AIエージェントの処理を見えるようにする 何を解決する機能か 9.5で何が変わったか 具体例 プライバシー上の注意 PromQL GA：Prometheus資産をElasticで活用しやすくする 何を解決する機能か 9.5で何が変わったか 移行ツール メトリック 注意点 Workflows：作成しやすく、壊しても戻しやすくする バージョン管理 Visual Mode 自然言語オーサリング Human-in-the-loop Security：AIによる調査とルール運用を強化 AlertZeroは製品名ではない Attack Discoveryの変化 検知ルール変更履歴 注意点 その他のGA機能 Dashboards API Cases as Data どの機能から試すべきか GA機能で優先度が高いもの 検証環境で試すTech Preview まとめ 参考資料 まず押さえたいGAとTech Preview Elastic 9.5の機能は、すぐに本番利用を検討できる GA（正式提供）と、まず検証環境で試すべきTech Preview に分かれます。 機能 状態 一言でいうと PromQL対応 GA 多くの既存PromQLをElasticで実行できる Dashboards API GA ダッシュボードをコードとして管理できる Cases as Data GA ケース情報を分析用データとして利用できる Workflowsの自然言語オーサリング GA 自然文からWorkflowの初稿を生成できる Workflowsのバージョン管理 GA 変更履歴の確認、比較、復元ができる 検知ルール変更履歴 GA ルールの変更内容と変更者を追跡できる Columnar Mode / Columnar Logs Tech Preview ログの保存容量を減らし、分析向けに最適化する VectorDB index mode Tech Preview ベクトル検索向けの設定をまとめて適用する DiskBBQ Auto-calibration Tech Preview 実データに合わせてベクトル検索設定を自動調整する マルチモーダルsemanticフィールド Tech Preview テキスト、画像、音声、動画、PDFを意味で検索する Agent Builder tracing Tech Preview AIエージェントの処理をトレースとして確認する Tech Previewの機能は、将来のElasticの方向性を理解するうえで重要ですが、本番利用の前に機能制約、性能、ライセンスを確認する必要があります。 Columnar Mode：ログを「検索中心」から「分析中心」へ 状態：Tech Preview 対象：大量のログを長期間保存し、ダッシュボードや集計で利用する環境 何を解決する機能か 通常のElasticsearchでは、1つのフィールドを検索、範囲検索、集計、元データの保持など、複数の目的に合わせて保存します。これは高い検索性能を実現する一方、ログのようにフィールド数が多いデータでは、保存容量が大きくなります。 実際のログ運用では、すべてのフィールドを全文検索するわけではありません。多くのフィールドは、ダッシュボードでの絞り込みや集計に使われます。 9.5で何が変わったか Columnar Modeは、非テキストフィールドを主に列形式で保存し、転置インデックスや数値範囲検索用のBKDツリーを既定では作りません。 ログ向けのlogsdb_columnarでは、messageなどのテキストフィールドには全文検索用の転置インデックスを残し、それ以外の構造化フィールドは列形式を中心に保存します。 PUT logs-example {   "settings": {     "index.mode": "logsdb_columnar"   } } なぜ役立つのか 列形式では、クエリに必要なフィールドだけを読みやすく、同じ種類の値が並ぶため圧縮もしやすくなります。 例えば、次のようなログ基盤に向いています。 1日に大量のログを取り込む service.nameやlog.levelごとの集計が多い Kibana Dashboardで傾向を見ることが中心 保存コストのため保管期間を短くしている 注意点 すべての検索が速くなるわけではありません。trace.idやpod.uidのようなランダムな値を1件だけ探す検索や、数値の範囲検索は、通常のインデックスより遅くなる可能性があります。 また、index.modeは作成後に変更できません。既存データへ適用するには、ロールオーバーまたはreindexが必要です。現時点では一律の削減率も公表されていないため、自社データで比較することが重要です。 ドキュメントの更新、nestedデータ、特定ドキュメントの取得、全文検索の関連度評価が中心の場合は、従来のインデックスモードのほうが適しています。 要点 ：保存と分析を優先するログには有望ですが、ピンポイント検索が多い環境では事前検証が必要です。 VectorDB index modeとAuto-calibration：ベクトル検索の初期設定を簡単にする 状態：Tech Preview 対象：RAG、セマンティック検索、画像検索などをこれから構築するチーム 何を解決する機能か ベクトル検索では、文章や画像を数値の並びであるベクトルへ変換し、意味の近さを距離で検索します。 ただし、大量のベクトルを扱うには、圧縮方法、検索候補数、メモリの使い方など、多くの設定が必要です。最適な値はデータによって変わるため、従来は性能と精度を測りながら手作業で調整する必要がありました。 VectorDB index mode vectordb_documentを指定すると、ベクトル検索に適した複数の設定がまとめて適用されます。 PUT my-vector-index {   "settings": {     "index.mode": "vectordb_document"   } } 主な目的は次のとおりです。 ベクトルの保存容量を抑える ベクトルを_sourceへ重複保存しない 重いセグメントマージを効率化する 検索で頻繁に使う構造を先読みする 個別の内部設定をすべて理解しなくても、ベクトル検索向けの初期状態から検証を始められます。 DiskBBQとAuto-calibration DiskBBQは、検索に必要なデータの多くをディスクへ置き、メモリへ載せるデータを減らすための検索方式です。大量のベクトルを、限られたRAMで扱いたい環境に向いています。 Auto-calibrationを有効にすると、Elasticsearchが実際のベクトルを調べ、圧縮方法や検索候補数などを自動的に選びます。 "index_options": {   "type": "bbq_disk",   "auto_calibrate": true } 正しいパラメータ名はauto_calibrateです。 注意点 Auto-calibrationは、精度を100%保証する機能ではありません。検索品質、レイテンシ、取り込み性能は実データで確認する必要があります。 比較的検索しやすいデータでは圧縮を強くし、難しいデータでは情報を多く残すことで、容量と検索精度のバランスを自動調整します。 bbq_diskにはEnterpriseライセンスが必要です。また、index.modeやauto_calibrateはインデックス作成後に変更できないため、既存データへ適用する場合はreindexが必要です。 要点 ：ベクトル検索の専門的な初期設定を減らす機能です。ただし、最終的な品質確認まで自動化されるわけではありません。 マルチモーダルsemanticフィールド：画像やPDFも意味で検索する 状態：Tech Preview 対象：図面、商品画像、スキャン文書、音声、動画を検索したいチーム 何を解決する機能か これまでのsemantic_textは、主にテキストを対象とした機能でした。画像や音声を検索するには、データの種類ごとに別のモデルやパイプラインを作る必要がありました。 9.5で何が変わったか 新しいsemanticフィールドは、次のデータを扱えます。 テキスト 画像 音声 動画 PDF これらを同じ埋め込みモデルでベクトル化することで、異なる種類のデータを意味の近さで検索できます。 例えば、次のような検索が可能になります。 「赤い花柄のワンピース」という文章から商品画像を探す 画像をクエリにして似た画像を探す 自然文から関連するPDFや図面を探す 音声から意味の近い音声や説明文を探す "my_semantic_field": {   "type": "semantic",   "inference_id": ".jina-embeddings-v5-omni-small" } 注意点 非テキストデータはdata URL形式で投入します。入力サイズは既定で1MBで、Serverlessでは1MB固定です。また、PDFなどは自動的にページ単位へ分割されないため、細かく検索したい場合は事前の分割設計が必要です。 事前定義されたJinaモデルはElastic Inference Serviceを利用します。データの送信先、料金、ライセンス、データ主権もPoC前に確認してください。 ページ単位で検索したい場合は、事前にPDFをページごとに分割して投入します。 また、重要な制約として、semanticフィールドは 9.5以降に作成されたインデックスで使用する必要がある ため、既存インデックスではreindexが必要になる場合があります。 要点 ：検索対象をテキスト以外へ広げる機能です。実務では、ファイルサイズ、分割方法、推論コストが導入判断のポイントになります。 Agent Builder tracing：AIエージェントの処理を見えるようにする 状態：Tech Preview 対象：Agent BuilderをPoCまたは運用で利用しているチーム 何を解決する機能か AIエージェントは、1つの質問に対して複数回LLMを呼び出したり、ES|QLなどのツールを実行したりします。 そのため、応答が遅い、トークン消費が増えた、意図しないツールを呼んだといった問題が起きても、原因を特定しにくいという課題があります。 9.5で何が変わったか Agent Builderは、エージェントの実行内容をOpenTelemetry形式のトレースとして記録できるようになりました。 確認できる主な情報は次のとおりです。 LLMを何回呼び出したか 各処理にどのくらい時間がかかったか どのツールを実行したか 入力・出力トークン数 どの処理で失敗したか トレースはElasticsearchへ保存されるため、Discover、ES|QL、Lens、Dashboard、アラートなど、既存のElastic機能で分析できます。 具体例 あるエージェントの応答時間とトークン使用量が突然増えたとします。 トレースを確認すると、ES|QLツールが大量の結果を返し、その内容が後続のLLM呼び出しへ何度も渡されていたことが分かるかもしれません。原因が分かれば、クエリにLIMITを追加する、ツールの説明を修正するといった対応ができます。 プライバシー上の注意 トークン数やモデル名などの構造的な情報は記録されますが、ユーザーのプロンプト、LLMの回答、ツールの結果などは既定では記録されません。 詳細内容を記録するとデバッグには便利ですが、個人情報や機密情報が含まれる可能性があります。保存期間とアクセス権限を含めた設計が必要です。 要点 ：AIエージェントを通常のアプリケーションと同じように監視し、性能・コスト・失敗原因を調べるための機能です。 PromQL GA：Prometheus資産をElasticで活用しやすくする 状態：GA 対象：Prometheus、Grafana、OpenTelemetryメトリックを利用しているチーム 何を解決する機能か PrometheusからElasticへ移行するとき、大きな負担になるのはデータ転送だけではありません。既存のGrafana Dashboardやアラートルールに書かれたPromQLを、別のクエリ言語へ書き換える作業が必要でした。 9.5で何が変わったか ElasticはPrometheus互換HTTP APIと、ES|QLから利用できるPROMQLコマンドをGAとして提供します。 PROMQL sum by (service.name) (rate(http_requests_total[5m])) GrafanaからElasticのPrometheus互換APIを参照することで、多くの既存PromQLを変更せず利用できます。また、PromQLの結果をES|QLパイプラインで後処理することもできます。 移行ツール Observability Migration Platformは、GrafanaやDatadogのダッシュボードとアラートをKibanaへ移行するためのCLIです。 変換できないパネルを無理に作成するのではなく、手動確認が必要な箇所を示す設計になっています。移行前に検証する–validateオプションも用意されています。 メトリック 9.5ではメトリック用コーデックも改善され、Elasticの説明では、メトリックの保存容量が前バージョンからさらに約20%削減されています。PromQL対応だけでなく、保存効率も改善されています。 注意点 PromQLとPrometheusが完全互換になったわけではありません。and、unless、group_left、group_rightなど、一部の構文や動作には制限があります。既存のGrafana Dashboardやアラートは、移行前に実データで確認する必要があります。 要点 ：Prometheus/Grafanaの既存資産を活かしたまま、Elasticへ段階的に統合しやすくする機能です。 Workflows：作成しやすく、壊しても戻しやすくする 状態：GA （利用プランとAgent Builder／LLM設定の確認が必要） 対象：Elastic Workflowsで運用自動化を行うチーム バージョン管理 9.5では、Workflowの変更履歴を確認し、差分比較や過去バージョンへの復元ができるようになりました。 自動化は、一度動けば終わりではありません。条件や接続先を変更した結果、処理が動かなくなることがあります。変更者、変更日時、変更内容を追跡できることで、障害調査と監査が行いやすくなります。 自然言語によるWorkflow作成を利用するには、Agent BuilderへのアクセスとLLMの設定が必要です。 Visual Mode Workflowを、トリガー、ステップ、分岐を含む図として確認できます。ただし、9.5時点では読み取り専用です。ドラッグ＆ドロップでWorkflowを作成する機能ではありません。 自然言語オーサリング 「アラートが発生したら関連ログを取得し、AIで要約してSlackへ送る」といった指示から、WorkflowのYAML初稿を生成できます。 生成されたWorkflowは、人間が確認してから実行します。自然言語だけで安全な自動化が完成するわけではなく、作成作業のスタートを速くする機能と考えるべきです。 Human-in-the-loop Workflowを途中で止め、人間の入力や承認を待つステップも利用できます。AIや自動処理にすべてを任せず、重要な操作だけ人間が判断する設計に役立ちます。 要点 ：Workflowsは「作る機能」だけでなく、変更管理、レビュー、承認を含む運用基盤へ進化しています。 Security：AIによる調査とルール運用を強化 対象：Elastic Securityを利用するSOC、セキュリティ運用チーム AlertZeroは製品名ではない AlertZeroは、新しい製品や機能の名前ではありません。大量のアラートをそのまま人間へ渡すのではなく、AIと自動化によって優先順位を付け、アナリストが重要な脅威へ集中できる状態を表す考え方です。 Attack Discoveryの変化 従来のAttack Discoveryは、複数のアラートを関連付け、攻撃のまとまりとして説明する役割が中心でした。 9.5では、Agent BuilderとWorkflowsを利用し、次のような追加調査を行う方向へ拡張されています。 関連する生イベントを検索する ユーザーやホストのリスク情報を確認する アラート以外の証拠を探す 調査結果をまとめる 見逃していた活動からES|QLルールの案を作る 別のAlert Analysisワークフローでは、アラートを真陽性と誤検知に分類します。これにより、アナリストが低品質なアラートへ費やす時間を減らし、Attack Discoveryもより整理された対象を調査しやすくなります。 作成されたルール案は、人間がレビューし、承認するまで検知ルールとして追加されません。 検知ルール変更履歴 検知ルールの作成、編集、有効化、無効化、例外の追加などを履歴として確認できます。変更前後の差分表示と、過去状態への復元も可能です。 例えば、例外条件を広く設定しすぎてルールが発火しなくなった場合でも、どの変更が原因だったかを追いやすくなります。 注意点 Attack Discoveryのエージェント的な調査では、複数回のLLM呼び出しとツール実行が発生します。調査品質だけでなく、トークン費用、データ送信先、機密情報の扱いを確認してください。 また、AIが作成したES|QLルールは、構文が正しくても、自社のログに必要なフィールドが存在しない、誤検知が多いといった可能性があります。人間によるテストとレビューは必要です。 なお、Agent BuilderとWorkflowsを使った新しいAttack Discoveryの動作は、詳細設定で有効化する必要があり、9.5では既定でオフです。 要点 ：SecurityのAIは、アラートを説明する段階から、証拠を探して調査を支援する段階へ進もうとしています。 その他のGA機能 Dashboards API Kibana Dashboardを構造化されたJSONとして作成・更新できます。Gitでの差分管理、レビュー、CI/CDによる環境間展開が行いやすくなります。 ただし、すべてのパネルタイプをAPIだけで扱えるわけではありません。既存Dashboardをコード管理へ移す場合は、対応パネルを確認してください。 Cases as Data ケース情報を分析用インデックスへ同期し、Discover、Lens、ES|QL、Dashboardから分析できます。 これにより、ケース件数、クローズ率、対応時間、担当者ごとの負荷などを確認できます。更新はリアルタイムではなく、反映に時間差がある点に注意してください。 どの機能から試すべきか GA機能で優先度が高いもの 現在の課題 最初に確認する機能 PrometheusやGrafanaから移行したい PromQL対応と移行CLI Dashboardを環境間で管理したい Dashboards API SOCの対応時間や負荷を測りたい Cases as Data Workflowの変更が怖い バージョン管理 検知ルールの変更原因を追えない 検知ルール変更履歴 検証環境で試すTech Preview 現在の課題 検証する機能 ログの保存費用が高い Columnar Logs ベクトル検索の設定が難しい VectorDB index mode / Auto-calibration 画像やPDFを意味で検索したい semanticフィールド Agent Builderの遅延や費用が分からない Agent Builder tracing Tech Previewでは、既存環境を直接変更するのではなく、小さな新規インデックスや限定したデータセットで比較するのが安全です。 まとめ Elastic 9.5は、次の3つの方向へ進んだリリースと整理できます。 データ保存を効率化する Columnar Modeにより、大量ログを分析と長期保存へ最適化します。 検索とAIの構築作業を減らす VectorDB index mode、Auto-calibration、マルチモーダルsemanticフィールドにより、ベクトル検索の開始を簡単にします。 AIと自動化を運用できる形にする Agent Builder tracing、Workflowのバージョン管理、Human-in-the-loop、検知ルール変更履歴により、AIと自動化を監視・修正・監査しやすくします。 そのほかにも、KubernetesとAWSのオンボーディングでは、推奨されるOpenTelemetry経路を使ってセットアップが簡素化、APMのService Map改善、LLM ObservabilityのAnthropic対応が追加されています。Elastic Defendでは、脆弱なドライバーに対する予防的保護、Windows on ARM対応、エンドポイントのトラブルシューティングスキルが追加されました。Workflowsでは、Slackなどの外部ツールから承認することもできます。 GA機能は既存運用への適用を検討し、Tech Previewは将来の設計判断に向けて小さく検証するのがよいでしょう。 参考資料 Elastic 9.5公式リリースブログ Columnar Mode dense_vector field type semantic field type Agent Builder traces PromQL overview PromQL limitations Elastic Workflows Attack Discovery Detection rule changes history Cases as Data The post Elastic 9.5の新機能を速報解説：保存、ベクトル検索、AI運用はどう変わるのか first appeared on Elastic Portal .

はじめに こんにちは、同志社大学理工学部情報システムデザイン学科4年生の金谷一輝です。 2026年7 ...