ClaudeとSplunkを連携してSPLクエリを自然言語で実行する

Claude Splunk連携でSPLを書かずにログ検索できる

Splunk LLCはSplunkbase(App ID 7931)で公式のMCP Serverを配布しています。Splunk Enterprise・Splunk Cloud Platformの両方に対応し、Claudeから「先週の異常な失敗ログイン数を教えて」のような自然言語の依頼をそのままSPL(Search Processing Language)クエリへ変換して実行できます。ステータスは「Splunk Supported・Beta」で、Splunk自身がサポート対象として位置付けているアプリです。

対応プラットフォームバージョンはSplunk 8.0〜8.2、9.0〜9.4、10.0〜10.2と広く、既存の環境に導入しやすい設計になっています。Splunkbase上では人工知能(Artificial Intelligence)カテゴリとIT Operationsカテゴリの両方に登録されており、監視・運用チームでの利用を想定した位置付けです。

アーキテクチャ: Splunkインスタンス内で動くHTTP/SSEサーバー

このMCP Serverはローカルでプロセスを起動するstdio型ではなく、Splunkインスタンス自体の中でホストされ、HTTP経由で公開される方式です。クライアントはSplunkの管理ポート(既定8089)の/services/mcpエンドポイントに接続します。

curl -k \
  -H "Authorization: Bearer <YOUR_TOKEN>" \
  -H "Content-Type: application/json" \
  -X POST \
  -d '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"client":"curl","version":"0.1"}}' \
  https://<YOUR_SPLUNK_HOST>:8089/services/mcp

初期化に成功すると、次のようなレスポンスでトランスポートとサーバーバージョンが確認できます。

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "protocolVersion": "2025-03-26",
    "capabilities": { "tools": {} },
    "serverInfo": { "name": "Splunk_MCP_Server", "version": "0.2.2" }
  }
}

capabilitiesが{"tools": {}}のみでresourcesやpromptsを宣言していないとおり、このサーバーはSplunkの機能をツールとしてのみ公開します。

Claude Code / Claude Desktopへの接続設定

管理ポートに直接HTTP接続するクライアントもありますが、Claude Code・Claude Desktopではmcp-remoteをローカルプロキシとして使い、Authorizationヘッダーを注入する方式が案内されています。

{
  "mcpServers": {
    "splunk-mcp-server": {
      "command": "npx",
      "args": [
        "-y",
        "mcp-remote",
        "https://<SPLUNK_HOST>:8089/services/mcp",
        "--header",
        "Authorization: Bearer <YOUR_TOKEN>"
      ],
      "env": {
        "NODE_TLS_REJECT_UNAUTHORIZED": "0"
      }
    }
  }
}

NODE_TLS_REJECT_UNAUTHORIZED: "0"は自己署名証明書を使っている社内Splunk環境向けの設定です。正規のCA証明書を使っている場合はこの行を外して構いません。

Cursor IDEなど他クライアントの設定

Claude以外のMCP対応クライアントでも、URLとヘッダーを直接指定する形で同じサーバーに接続できます。Cursor IDEの例です。

{
  "mcpServers": {
    "splunk-mcp-server": {
      "url": "https://<SPLUNK_HOST>:8089/services/mcp",
      "headers": {
        "Authorization": "Bearer <YOUR_TOKEN>"
      }
    }
  }
}

mcp-remoteを挟まず直接HTTP接続する形式で、クライアント側がリモートMCPサーバーへのネイティブ接続に対応していればこの書き方が使えます。

Splunkが謳う3つの特徴

公式ドキュメントは本サーバーの強みを3点に整理しています。

• Universal Connectivity(汎用接続性): AIエージェントやツールをSplunkのデータリソースへ安全かつ効率的に接続する
• Enterprise-Grade Security(企業レベルのセキュリティ): 認証・認可・RBACを組み込み、既存のSplunk認証とアクセス制御にそのまま従う。悪意あるペイロードやコマンドインジェクションを監視するための監査・ログ・入力検証にも対応する
• Rapid Deployment(迅速な導入): プラグアンドプレイ型で、個別カスタム連携の実装が不要

3点目の「迅速な導入」は、Splunk側にアプリをインストールするだけで済み、別途MCPサーバーのホスティング環境を用意しなくてよいことを指します。

できることの中心は3つ

Core Capabilitiesとして案内されているのは次の3点です。

1. データの探索: Splunkのデータをナビゲートし、対話的に操作する
2. ナレッジオブジェクトの発見: 保存済み検索・ルックアップなど関連するナレッジ資産を特定してアクセスする
3. 検索の実行: 強力なSplunkクエリを実行してインサイトを抽出し、インテリジェントなワークフローを駆動する

これに加えて、SplunkのAI Assistant機能を呼び出せる点が、単なる「検索実行の窓口」以上の価値になっています。SPLを一から書ける人でなくても検索を任せられる設計です。

よくあるつまずき

• Authorizationヘッダーを付け忘れる: 管理ポートへの直接接続もクライアント設定も、トークンをヘッダーで渡し忘れると初期化リクエスト自体が失敗します
• authorize.confのロール権限を付け忘れる: mcp_tool_executeが有効になっていないロールのユーザーは、MCP接続自体はできてもツール実行時にエラーになります
• 自己署名証明書を使う環境でSSL設定を揃え忘れる: クライアント側のNODE_TLS_REJECT_UNAUTHORIZEDとSplunk側mcp.confのssl_verifyは別々の設定なので、どちらか一方だけ変更すると接続エラーが解消しないことがあります
• 管理ポートへの到達性を見落とす: /services/mcpは管理ポート(既定8089)経由です。通常の検索用ポートしか開放していないネットワーク構成では接続できません
• mcp_tool_adminとmcp_tool_executeを混同する: authorize.confの権限ケイパビリティはこの2つに分かれています。検索やツール呼び出しに必要なのはmcp_tool_executeで、mcp_tool_adminはMCP機能自体の管理権限です。実行だけさせたいユーザーにadminまで含めて付与すると、想定より強い権限を渡すことになります

既存のSplunk RBACをそのまま継承する

このMCP Serverの最大の特徴は、独自の権限モデルを新しく作らず、Splunk側の既存の認証・アクセス制御をそのまま使うアーキテクチャです。AIがアクセスできるデータは、接続に使ったトークンのユーザーがもともとSplunkで見られる範囲に限定されます。

MCP機能を使わせるには、authorize.confでロールに権限ケイパビリティを付与します。

[role_mcp_user]
mcp_tool_admin = enabled
mcp_tool_execute = enabled

sc_adminロールはMCP機能自体の管理権限を持ちます(v1.0.0で追加)。AIとのやり取りはすべて既存のSplunk RBACに従うため、あるユーザーが検索できないインデックスは、そのユーザーのトークンで動くAIからも検索できません。

利用できるツール

これに加えて、v1.0.0で追加された組み込みのツールUIから、上記以外の追加ツールも確認できます。破壊的な操作(データ削除等)を防ぐガードレールが組み込まれている旨も明記されています。

generate_splはSplunk自身のAI Assistant機能を利用しており、SPL生成だけでなく検索の最適化・検索内容の説明・MLTKモデルとアルゴリズムの取得といったAI支援機能も呼び出せます。

SSL設定

mcp.confでSSL検証の有無を切り替えられます。

[mcp]
ssl_verify = true   # 自己署名証明書の場合は false

Splunk側の証明書設定と、クライアント側のNODE_TLS_REJECT_UNAUTHORIZEDは別レイヤーの設定なので、どちらか一方だけ変更しても接続エラーが解消しないことがあります。

実務での使い方の例

セキュリティ運用: 「過去1時間で外部IPからのログイン失敗をすべて見せて」と聞くと、MCP Serverが該当するSPL検索を実行し、簡潔なレポートとして結果を返します。

DevOps: 「Kubernetesクラスタのログのパフォーマンス傾向はどうなっている?」という依頼から、関連ログを取得して傾向を要約させる使い方ができます。

複数アプリ連携: SplunkのシステムナレッジをまとめたConfluence MCP Serverと本サーバーを組み合わせることで、より正確な洞察を得られるという使い方も紹介されています。

バージョン履歴

初回提供(2025年9月)から1.0.1(2026年2月)まで一貫して、認証・証明書まわりの堅牢化とRBAC機能の拡充が続いています。Splunkbase上のステータス表記は「Splunk Supported・Beta」です。

導入前に確認しておきたいこと

本番のSplunk環境に接続する前に、次の3点を確認しておくと事故を防げます。

1. 接続に使うトークンの権限範囲: そのトークンでSplunk上から見えるインデックス・保存済み検索が、AIに調べさせたい範囲と一致しているか
2. 管理ポートへのネットワーク到達性: 8089ポートがクライアント環境からSplunkインスタンスへ到達できるか。ファイアウォールで検索用ポートしか開けていない構成では別途穴を開ける必要がある
3. authorize.confのロール設計: mcp_tool_executeを誰に付与するかは、既存のSplunkロール設計の延長として決める。新しいロールを作るか既存ロールに追加するかはチームの運用方針次第

まとめ

Splunkの公式MCP ServerはSplunkインスタンス内で動くHTTP/SSEサーバーで、管理ポート8089経由で接続し、既存のSplunk RBACをそのまま権限境界として使います。Claude Code・Claude Desktopからはmcp-remote経由でAuthorizationヘッダーを注入する形が案内されており、generate_splでSPLを書かずに検索を実行できます。導入時はauthorize.confのロール設定とSSL検証の両方を確認してから接続するのが安全です。

同じ監視・可観測性の連携ではPrometheusのMCPサーバーがメトリクス側を、Kubernetes MCPサーバーがクラスタ操作側を担います。ログ・メトリクス・インフラ操作を別々のMCPサーバーに分担させることで、それぞれのRBACを保ったまま調査範囲を広げられます。