Splunk Enterprise 10.2は2026年1月15日に公開されたマイナーバージョンです。SPL2とSplunk AI Assistant for SPLの搭載、Node.jsの削除、rootでの起動の既定禁止など、運用に効く変更がまとまって入りました。その後、10.2.1(2026年2月27日)から10.2.8(2026年9月29日)まで、ほぼ毎月メンテナンスリリースが出ています。
なお、2026年10月時点のSplunk Enterpriseの最新版は10.6(2026年9月30日公開)です。この記事は10.2系に絞り、10.2公式リリースノート・10.2アップグレード手順・Splunk Software Support Policyをもとに、10.2で何が変わったか、どの版からどう上げるか、10.2に留まるか10.4以降へ進むかを整理します。Splunkそのものの仕組みやSPLの基本はSplunkとは?SPLの書き方・Docker検証環境と料金の実額を実装者向けに解説で扱っています。
まとめ:Splunk Enterprise 10.2で押さえる変更点と更新の要点
- 10.2.0の公開は2026年1月15日、10.2系の直近パッチは10.2.8(2026年9月29日)です。
- 主な新機能はSPL2(SPLとSQLの両構文で書ける検索言語)、サーチ画面に統合されたAI Assistant for SPL、Edge ProcessorのParquet出力、Agent ManagementでのForwarderとOTel Collectorの一元管理です。
- アップグレードで壊れやすいのは、rootでの起動の既定禁止、Node.jsの削除、Edge Processorの対応OS縮小、フェデレーテッドプロバイダー名の大文字小文字の統一の4点です。
- 10.2へ直接上げられるのは9.4.xと10.0.xからです。9.2.x・9.3.xは9.4.xか10.0.xを経由します。
- 10.2へ上げるとKV Storeはサーバーバージョン8.0へ自動で移行します(起動から60秒後に開始)。事前にKV Storeのバックアップを取ります。
- 10.2のサポート終了日は2028年1月15日です。10.4はKV StoreをMongoDB 8.0へ上げるため、9.x系からは10.0か10.2を一度経由する必要があります。
Splunk Enterprise 10.2.xの公開日と更新履歴
10.2系はメジャー機能を入れた10.2.0のあと、修正だけのメンテナンスリリースが続いています。公式の「What’s new」では、10.2.1以降のどの版も「It resolves the issues described in Fixed issues.」とだけ書かれており、新機能の追加はありません。
10.2.0〜10.2.8の公開日一覧
| バージョン | 公開日 | 種別 |
|---|---|---|
| 10.2.0 | 2026年1月15日 | マイナーリリース(新機能) |
| 10.2.1 | 2026年2月27日 | メンテナンス |
| 10.2.2 | 2026年3月31日 | メンテナンス |
| 10.2.3 | 2026年4月30日 | メンテナンス |
| 10.2.4 | 2026年5月29日 | メンテナンス |
| 10.2.5 | 2026年6月30日 | メンテナンス |
| 10.2.6 | 2026年7月29日 | メンテナンス |
| 10.2.7 | 2026年8月10日 | メンテナンス |
| 10.2.8 | 2026年9月29日 | メンテナンス |
パッチの中で挙動が変わった例外が1つあります。フィールドフィルター(検索結果の機密フィールドを伏せる機能)は10.2.2から既定で表示されるようになり、limits.confとweb-features.confでの有効化が不要になりました。公式は「Not available in Splunk Enterprise versions 10.2.0 and 10.2.1.」と明記しています。PIIのマスキングを10.2で使うなら、10.2.2以上が前提です。ただし10.2ではPreview Update 2として提供されており、ESの検知や高速化データモデル、mstats・mpreviewへの影響を確認してから本番導入を判断します。
セキュリティ修正の確認先はSecurity Advisories
10.2.8のFixed issuesページには、セキュリティ関連の修正はCisco Security Vulnerability Policyに従ってSplunk Security Advisoriesだけで開示する、という注記があります。リリースノートの修正一覧だけを見てパッチ適用の要否を決めると、脆弱性修正を見落とします。10.2系で修正版が10.2.xになっている主なアドバイザリは次のとおりです。
| アドバイザリ | 修正版 | CVSSv3.1 | 内容 |
|---|---|---|---|
| SVD-2026-0305 | 10.2.1 | 5.4 | 低権限ユーザーによるAPIトークン取得(更新後にトークンのローテーションも必要) |
| SVD-2026-0401 | 10.2.2 | 6.6 | edit_user権限で細工したユーザー名を作成 |
| SVD-2026-0505 | 10.2.3 | - | 同梱のGo関連パッケージのCVE修正 |
| SVD-2026-0603 | 10.2.4 | 9.8 | PostgreSQLサイドカー経由で認証なしにファイル作成・切り詰め |
| SVD-2026-0801 | 10.2.6 | 最大9.4 | REST API・Splunk Webなどの複数の脆弱性 |
最も重いSVD-2026-0603(CVE-2026-20253)は、10.2.0〜10.2.3が対象で、ネットワークから到達できれば認証なしで悪用できる種類です。すぐに上げられない場合はPostgreSQLサイドカーの無効化が回避策になりますが、Edge Processor・OpAmp・SPL2データパイプラインを使うインスタンスには適用できません。公式は、これらの機能が停止し、依存するサイドカーにも影響すると警告しています。またSVD-2026-0801は、一部のCVE(CVE-2026-76338・CVE-2026-76352)について10.2.6への更新に加えて追加の作業が要ると明記しています。10.2系の運用では、Splunk Security Advisoriesで影響版と修正版を確かめ、同じ10.2系の最新パッチへ上げるのが基本です。
Splunk Cloud Platformとの版番号の違い
Splunk Enterpriseは10.0・10.2・10.4・10.6と偶数番号だけが出ています。サポートポリシーの表では、10.1(2025年10月28日)・10.3(2026年3月24日)・10.5(2026年6月30日)はSplunk Cloud Platformだけの版で、Enterprise側は「Not Released」です。オンプレミスの10.2から次に上げる先は10.3ではなく10.4です。また10.6からは、Enterpriseとクラウドで「Major.Minor.Maintenance.Patch」の4つ組の版番号(例:10.6.0.5)に統一されます。版文字列を解析するスクリプトやCMDB連携は、10.6へ上げる前に4つ組で壊れないか確認が要ります。
Splunk Enterprise 10.2の主な新機能
SPL2とAI Assistant for SPLによる検索の変化
SPL2はSPLを拡張した検索言語で、公式は「With SPL2, you can write searches using either SPL or SQL syntax.」と説明しています。インデックスの検索、フェデレーテッドなデータストアへのアクセス、取り込み時のデータ加工(Edge Processor)を同じ構文で書けるのが狙いで、既存のSPLとは並行して動きます。Dashboard StudioでもSPL2のデータソースを使えるようになりました。
ただし、SPL2は条件付きです。クラスタ構成ではPostgresのポートが他のメンバーから到達可能でないとSPL2が使えず、10.2ではSPL2をサポートしないLinuxのバージョンもあります(SPL2 Known Issuesに記載)。既存のSPL資産を書き換える必要はないので、新しい検索から試し、クラスタではネットワーク要件を先に満たすのが現実的な順序です。
Splunk AI Assistant for SPLは、自然言語からSPLの生成・解説・変換を行う機能で、10.2からハイブリッドのオンプレミス環境でもサーチ&レポーティングアプリの中で使えます。利用にはSplunk AI Assistant for SPLアプリのバージョン1.3.2以上が必要です。
Edge ProcessorとAgent Managementによるデータ取り込みの変化
- Edge ProcessorからAmazon S3へ送るデータを、Parquet形式で保存できるようになりました。
- Edge ProcessorのHTTP Event Collector入力で、JSON配列(角括弧で囲みカンマ区切りのオブジェクト)を受け付けます。
- パイプラインごとの入出力量やログを見られる監視ダッシュボードが入りました。
- Agent ManagementでForwarderとOpenTelemetry Collectorを1つのコンソールで管理でき、OpAMPで通信するCollectorの実行中の設定を確認できます。
- Agent ManagementからS3とファイルシステムの宛先を設定し、接続中のエージェントへ配布できます(limits.confの
enableS3ConfigOnDsで有効・無効を切り替え)。
OpenTelemetry Collectorの構成そのものについてはOpenTelemetry Collector Contribとは|coreとの違いとocbで作る自作distro、軽量なログ転送の選択肢はFluent Bitとは?読み方・Fluentdとの違い・AWSでの設定例【v5.1対応】で解説しています。
運用・セキュリティ面の追加機能
| 機能 | 要点 |
|---|---|
| OAuth 2.0 | 外部アプリのREST API接続に外部認可サーバーを利用 |
| Audit Trail Log v2 | CIM準拠・JSON形式の監査ログ |
| Ingest-Tier Scaling | 取り込み層とインデックス層を分離して拡張 |
| Bulk Data Move | 検索条件でインデックス間のデータを移動(SmartStore以外のクラスタ限定) |
| アドホック検索のキュー上限 | システム単位・ロール単位で上限を設定 |
| CSVルックアップの複製上限 | server.confで既定5GBより低く設定可能 |
| サイドカー間のTLS検証 | 直接ポートの通信で証明書を検証 |
10.2へのアップグレードで影響が出る変更点
公式の「About upgrading to 10.2 READ THIS FIRST」は、前のリリースへ戻す方法は用意されていないと明記しています。以下は上げてから気付くと戻れない変更です。
rootでの起動の既定禁止
*nix環境では、Splunk Enterprise 10.2はrootユーザーでの起動を既定で拒否し、エラーで止まります。一時的な回避策は--run-as-rootを付けて起動することです。
$SPLUNK_HOME/bin/splunk start --run-as-root
これはあくまで一時しのぎです。10.4ではLinuxでのroot実行自体がサポート外になり、--run-as-rootが効くのはstart・stop・restartだけになります。systemdのユニットや起動スクリプトがrootで動いているなら、10.2へ上げる前に専用ユーザーへの所有権変更まで済ませておくと、10.4で同じ作業を繰り返さずに済みます。
Node.jsの削除とPython 3.13
10.0で非推奨になっていたNode.jsのランタイムは、10.2で削除されました。Node.jsを使うアプリやアドオンは、自前でNode.jsのビルドを同梱しない限り動きません。Pythonは、Splunk Webが3.13だけを使い、プラットフォームの既定は3.9のままで3.13へのオプトインが可能です。10.4では3.13が既定になり、3.9はフォールバックに下がります。自社開発のアプリは10.2の段階で3.13での動作確認を始めておくのが安全です。
Edge Processorの対応OSの縮小
10.2はCVE対応でGoのライブラリを更新した結果、Edge Processorが動くOSが変わりました。データ管理コントロールプレーンやEdge Processorが非対応OSのまま10.2へ上げると、Edge Processorがクラッシュしデータを失うと公式は警告しています。
| サポート外になったOS | 新たにサポートされたOS |
|---|---|
| Amazon Linux 2 | Debian 12以上 |
| CentOS 7 | RHEL 9.0以上 |
| Debian 10・11 | Rocky Linux 9以上 |
| RHEL 8.0 | SUSE Linux Enterprise 15 SP6以上 |
| SUSE Linux Enterprise 15.0 | Ubuntu 24.04 LTS |
| Ubuntu 20.04 LTS | - |
影響を受けるのはEdge Processorを使うマシンだけで、それ以外のSplunkコンポーネントのOSは対象外です。
フェデレーテッドプロバイダー名の大文字小文字の統一
フェデレーテッド検索(Splunk同士をつなぐ方式)のプロバイダー名は、10.2から大文字小文字を区別しなくなりました。「MyProvider」と「myprovider」のように大文字小文字だけが違うプロバイダーが既にある場合、10.2はfederated.confで先に現れたスタンザだけを参照します。Splunk Webからは名前を変えられないため、上げる前にプロバイダーを作り直すか、federated.confを直接編集して一意の名前にしておきます。
Fishbucketのバックエンド置換とダウングレード時の重複取り込み
ファイル監視のチェックポイントを保存するFishbucketは、10.2で新しいバックエンドに置き換わりました。アップグレード時の作業は不要ですが、10.2から以前の版へ戻すと、アップグレード後に作られたチェックポイントを失い、ファイルの一部を再取り込みしてイベントが重複する可能性があると公式は説明しています。「問題が出たら戻せばよい」という前提は10.2では成り立ちません。
9.x・10.0から10.2へのアップグレード経路と手順
現行バージョン別のアップグレード経路
| 現行バージョン | 最初の移行先 | 次の移行先 |
|---|---|---|
| 9.2.x | 9.4.xまたは10.0.x | 10.2.x |
| 9.3.x | 9.4.xまたは10.0.x | 10.2.x |
| 9.4.x | 10.2.x(直接) | 不要 |
| 10.0.x | 10.2.x(直接) | 不要 |
公式の表では9.2.xの中間先に9.3.xも並びますが、注記で「9.3.xへの更新は可能でも、10.2.xへの中間ステップとしてはサポートしない」とされています。9.2.xからは9.4.x以上を経由します。Universal Forwarderは10.0.x以上から10.2へ直接上げられます。
事前確認:CPU命令セットとKV Storeのバックアップ
9.4以降、Splunk Enterpriseを動かすマシンにはAVX・SSE4.2・AES-NIに対応したx86-64のCPUが必要です。KV Storeのデータベースエンジンがこれらの命令セットを前提にしているためで、非対応のCPUではアップグレードが失敗します。Linuxでは次のコマンドで3つすべてが出るか確認できます。
grep -o -w -E 'avx|sse4_2|aes' /proc/cpuinfo | sort -u
出力にaes・avx・sse4_2の3行がそろえば要件を満たしています。仮想マシンでは、ハイパーバイザーのCPU互換モードでAVXが隠されていることがあるので、物理ホストではなくゲストOS上で確認します。
KV Storeのバックアップは、$SPLUNK_HOME/binで実行します。まずbackupRestoreStatusとstatusが両方readyであることを確認し、outputlookupを既定のappend=fで実行する検索を完了させます。次にsplunk enable kvstore-maintenance-modeでメンテナンスモードを有効にしてから、以下のバックアップを実行します。完了を確認した後はsplunk disable kvstore-maintenance-modeで解除します。-pointInTime trueを付けないと、整合性のあるリストアができません。アーカイブは$SPLUNK_DB/kvstorebackupに作られます。
./splunk show kvstore-status
./splunk enable kvstore-maintenance-mode
./splunk backup kvstore -pointInTime true
./splunk disable kvstore-maintenance-mode
このほか、ext2ファイルシステムを使うLinuxはext3以上へ、Azureのリモートストレージでremote.azure.tenant_idとremote.azure.client_idを使っている場合は暗号化対象に加えるか値を消すか、のどちらかを事前に済ませます。Enterprise SecurityやITSIなどのプレミアムアプリは、Splunk Products Version Compatibility Matrixで10.2対応版があるかを先に確かめます。
アップグレード後のKV Store 8.0自動移行の確認
10.2へ上げると、KV Storeはサーバーバージョン8.0へ自動で移行します。単一インスタンスなら初回起動から60秒後、サーチヘッドクラスタなら全メンバーが同じ版になってから60秒後に始まります。Splunk自体は稼働を続けますが、移行中はKV StoreのCRUD操作、バックアップ・復元、再同期などが利用できません。KV Storeへの大量書き込みは避けてください。移行中の書き込みは、ロールバック時に保存されません。移行前にはディスクの空きが50%を超えていることとKV Storeの正常性に加え、CPU要件、LinuxのGNU C Library 2.27以上、クラスタの正常性、カスタム証明書やOCSP通信の条件も確認します。4.2から8.0への直接移行もできます。
splunk show kvstore-status --verbose
出力がserverVersion : 8.0.xなら移行済み、versionUpgradeInProgress : 1なら移行中です。KV Storeが不健全な状態のときは、server.confの[kvstore]スタンザでkvstoreUpgradeOnStartupEnabledをfalseにして自動移行を止め、サポートに相談するよう公式は案内しています。10.2はサーバーバージョン7.0も引き続きサポートしますが、将来の版では7.0が外れると予告されています。
単一インスタンスの更新手順とバージョンの確認
以下はLinuxの単一インスタンスをtarパッケージで更新する例です。事前にKV Storeだけでなく設定・インデックスデータ・バイナリもバックアップし、復元可能であることを確認します。サービス停止後は自動再起動を防ぎ、既存と同じインストール先・所有者で展開してから起動します。RPMなどで管理している環境は、該当するパッケージ更新手順に従います。
$SPLUNK_HOME/bin/splunk stop
# ダウンロードした10.2.xのtgzの絶対パスに置き換える
SPLUNK_PACKAGE="/path/to/splunk-10.2.x-linux-amd64.tgz"
tar xzf "$SPLUNK_PACKAGE" -C /opt
$SPLUNK_HOME/bin/splunk start
$SPLUNK_HOME/bin/splunk version
起動時に「Perform migration and upgrade without previewing configuration changes? [y/n]」と聞かれたら、nを選ぶと設定ファイルの変更内容が$SPLUNK_HOME/var/log/splunk/migration.log.<timestamp>に書き出され、サービスは起動しません。内容を確認してから再度起動すると移行が進みます。インデクサクラスタやサーチヘッドクラスタは手順が別なので、公式の「Upgrade an indexer cluster」「Upgrade a search head cluster」に従います。
サポート終了日から見た10.2・10.4・10.6の選び方
Splunk Enterpriseのサポート終了日一覧
Splunk Software Support Policyでは、Splunk Enterpriseの各マイナーバージョンは公開から24か月サポートされます。
| バージョン | 公開日 | サポート終了日 |
|---|---|---|
| 9.3 | 2024年7月24日 | 2026年7月24日(終了済み) |
| 9.4 | 2024年12月16日 | 2026年12月16日 |
| 10.0 | 2025年7月28日 | 2027年7月28日 |
| 10.2 | 2026年1月15日 | 2028年1月15日 |
| 10.4 | 2026年5月18日 | 2028年5月18日 |
| 10.6 | 2026年9月30日 | 2028年9月30日 |
9.4は2026年12月16日にサポートが終了します。サポートを途切れさせないため、9.4系の環境はこの日までに対応する10.x系への移行を完了できるよう計画します。
10.4・10.6のKV Store・実行環境・通信要件の変更
- 10.4はKV StoreとKV ServiceのバックエンドをMongoDB 8.0へ上げ、MongoDB 4〜6を同梱しません。公式は9.x以下の環境に対し、MongoDB 4.x・6.xから8への直接更新はサポートしないため、まず10.0か10.2へ上げるよう案内しています。
- 10.4はLinuxでのroot実行をサポート外にし、Python 3.13を既定にし、TLS 1.0・1.1を既定で無効にします(TLS 1.3を追加)。
- 10.4はConfig Validation(.confの変更を本番反映前にスキーマや互換性ルールで検証)とHTTP/2対応のSplunk Webを追加しました。HTTP/2はLinux・macOSが対象で、既定では無効のため有効化が必要です。
- 10.6はKV StoreのバックエンドをPostgreSQLへ移し、TLS 1.0・1.1を完全に削除し、版番号を4つ組に変えます。
- 10.6のフェデレーテッド検索は接続先の検証を強め、リモートのサーチヘッドが10.4未満だとフェデレーテッド検索が失敗します。
10.2に留まる環境と10.4以降へ進む環境の判断
9.x系から上げる環境は、10.2を目的地にするのが手堅い選択です。10.4へ進むにしてもKV Storeの事情で10.0か10.2を一度経由する必要があり、10.2で止めれば2028年1月15日まで同じ系列のパッチで運用できます。プレミアムアプリの対応版がそろうまで待つ必要がある環境も、10.2が受け皿になります。
一方、次の条件に当てはまる環境は10.2を経由点と考え、10.4以降まで計画に入れます。フェデレーテッド検索で複数のSplunk環境をつないでいる場合は、10.6でリモート側に10.4以上が要るため、接続先の版をそろえる計画が先に必要です。証明書の公開CAがClient Authentication EKUを外す変更の影響を受ける環境は、KV Storeのクライアント側TLSを独立して設定できる10.4の機能が対策になります。自社アプリがLinuxでのroot実行を前提にしている場合は、非root実行への改修が先です。Python 3.9に依存する場合は、10.4でも残るフォールバックの適用可否とアプリの互換性を確認し、3.13への移行を計画します。
クラウド型のログ基盤やSIEMと比較している段階なら、SIEMとは?仕組みとIPS・SOC・EDRとの違いをわかりやすく解説【2026年】で製品の位置づけを、可観測性側の選択肢はO11y Cloud Free Edition徹底ガイド|15ホスト無期限無料で始めるSplunk可観測性を参照してください。
よくある質問
Splunk Enterprise 10.2はいつ公開されましたか?
10.2.0は2026年1月15日に公開されました。メンテナンスリリースは10.2.1(2026年2月27日)から10.2.8(2026年9月29日)まで出ています。
Splunk Enterpriseの最新バージョンはいくつですか?
2026年10月時点の最新のマイナーバージョンは10.6(2026年9月30日公開)です。10.2系の最新パッチは10.2.8です。手元の版はsplunk versionコマンドで確認できます。
10.2.1や10.2.2で新機能は追加されましたか?
いいえ。10.2.1以降のメンテナンスリリースは修正のみです。ただし、フィールドフィルターが既定で使えるようになったのは10.2.2からで、10.2.0と10.2.1では使えません。
Splunk Enterprise 10.2のサポートはいつまでですか?
2028年1月15日までです。各マイナーバージョンは公開から24か月サポートされ、9.4は2026年12月16日、10.0は2027年7月28日に終わります。
Splunk 9.3から10.2へ直接アップグレードできますか?
できません。9.3.xはいったん9.4.xか10.0.xへ上げてから10.2.xへ進みます。直接上げられるのは9.4.xと10.0.xです。