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」で、Splunkbaseの概要には、EnterpriseとCloudの利用者向けに提供中であること(ベータ)も書かれています。

最初に押さえたいのは、情報源が2つあってバージョンがずれていることです。GitHubのREADMEは1.0.1(2026年2月7日)の内容で、Splunkbaseの現行は2.0.0(2026年9月3日)です。手順の骨格は同じでも、対応するSplunkのバージョンとツール名が違います。この記事は両方を突き合わせて、どちらの記述を読むべきかを項目ごとに示します。

READMEとSplunkbaseで食い違う3点

食い違いは3点あります。1点目は対応バージョンで、Splunk 9.2以前や8系で使う予定なら、SplunkbaseのリリースごとのCompatibilityを先に見る必要があります。Splunkbaseに載っている1.2.1・1.3.0・1.3.1・2.0.0は、どれも9.3〜10.6が対象です。

2点目はツール名です。2.0.0のリリースノートはsplunk_run_queryと書き、1.3.0のリリースノートはrun_splunk_queryと書いています。READMEの表と同じ綴りです。どちらの名前で見えるかは入れたバージョンで決まるので、Claudeに頼む前に、接続したクライアントが列挙したツール名を確かめると食い違いに悩まずに済みます。

3点目は既定の検索範囲です。時間範囲を付けないsplunk_run_queryの呼び出しは、2.0.0で直近24時間から直近6時間に変わりました。「ログイン失敗を見せて」とだけ頼むと、古いバージョンより狭い範囲しか見ない可能性があります。依頼文に期間を書くのが確実です。

アーキテクチャ: 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

READMEに載っている初期化のレスポンスは次のとおりです。

{
  "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の機能をツールとしてのみ公開します。protocolVersionはREADMEの例で2025-03-26ですが、1.3.1のリリースノートにはMCPプロトコルのバージョンを2025-11-25に更新したと書かれています。プロトコルのバージョンは1.3.1で更新されたため、手元の応答がREADMEの例と異なる場合があります。

疎通から登録までの5ステップ

本番のSplunkにつなぐ前に、次の順で進めると原因の切り分けがしやすくなります。

Claude Code / Claude Desktopへの接続設定

Claude CodeとClaude Desktopについて、READMEは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"は、READMEでは自己署名証明書を使う場合の設定として書かれています。正規のCA証明書を使っている環境では、この行は要りません。

claude mcp addで直接登録する

Claude Codeはclaude mcp addでHTTPのMCPサーバーを直接登録でき、ヘッダーも付けられます。v2.1.289のclaude mcp add --helpには、ヘッダー付きでHTTPサーバーを追加する例と、次のオプションが載っています(抜粋)。

Options:
  -H, --header <header...>     Set headers for HTTP/SSE servers (e.g. -H
                               "X-Api-Key: abc123" -H "X-Custom: value")
  -s, --scope <scope>          Configuration scope (local, user, or project)
                               (default: "local")
  -t, --transport <transport>  Transport type (stdio, sse, http). Defaults to
                               stdio if not specified.

この書式をSplunkに当てはめると、次の1行になります。

claude mcp add --transport http splunk \
  https://<SPLUNK_HOST>:8089/services/mcp \
  --header "Authorization: Bearer <YOUR_TOKEN>"

mcp-remoteを挟まないぶん構成要素が1つ減りますが、READMEが案内しているのはmcp-remote経由の形です。トークンを含む設定をプロジェクトのファイルにコミットしないよう、--scopeは既定のlocalのままにする選択肢もあります。自己署名証明書の環境で直接登録した場合にTLS検証がどう扱われるかはREADMEに書かれていないため、先に上のcurl(-k付き)で疎通だけ確かめるのが安全です。

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を挟まない直接接続の形式で、クライアントがリモートMCPサーバーにネイティブ対応していれば使えます。

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

このMCP Serverは独自の権限モデルを作らず、Splunk側の既存の認証・アクセス制御をそのまま使います。AIがアクセスできるデータは、接続に使ったトークンのユーザーがSplunkで見られる範囲に限られます。あるユーザーが検索できないインデックスは、そのユーザーのトークンで動くAIからも検索できません。

MCP機能を使わせるロールには、authorize.confでケイパビリティを付与します。READMEのサンプルは次のとおりです。

[role_mcp_user]
mcp_tool_admin = enabled
mcp_tool_execute = enabled

sc_adminロールにはMCP機能を管理する権限があります(1.0.0で追加)。2つのケイパビリティのうち、mcp_tool_adminはリリースノートに役割が出てきます。1.3.0では、このケイパビリティを持たないユーザーにはカスタムツールの「Create tool」ボタンが無効表示になります。1.2.1では、持たないユーザーがツール管理を試みると専用のメッセージが出ます。文面は「You do not have the mcp_tool_admin capability required to manage tools.」です。つまりmcp_tool_adminはツールを作る・管理する側の権限です。検索だけさせるロールに付けるかどうかは、この2つの挙動を基準に判断します。

1.3.0ではMCPツール自体にもロールベースのアクセス制御が入り、ツールを使えるロールを絞れるようになりました。Governanceタブには、どのロールがどのツールにアクセスできるかを示すパネルが加わっています。

利用できるツール

READMEが挙げるツールは次の6つです。

READMEにはこれ以外の追加ツールが組み込みのツールUI(1.0.0で追加)で見えるとあり、破壊的な操作を防ぐガードレールがあるとも書かれています。generate_splはAI支援のツールとして載っています。READMEはSplunk AI Assistantの機能として、SPLの生成・最適化・説明と、MLTKモデル・アルゴリズムの取得を挙げています。

2.0.0のリリースノートが挙げる追加分は、運用の調べ物に直結します。

1.3.0ではMCP Tool Annotationsが加わり、読み取り専用のツールと書き込みできるツールを見分けられます。2.0.0では全組み込みツールにopenWorldHintアノテーションが付きました。カスタムツールにはSPL型とAPI型の2種類があります。

2.0.0には、既存の使い方を変える点もあります。splunk_get_metadataではソースタイプの探索ができなくなり、splunk_get_sourcetypesを使う形に移りました。splunk_get_indexesはインデックスの識別子をtitleでなくnameで返します。Splunk AI Assistantのデータ探索ツールを使うには、Splunk AI Assistant 2.2.0以降でAgent Modeを有効にする必要があります。プロンプトとクエリの最大長は10,000文字です。

管理者が使えるガードレール

READMEの「破壊的な操作を防ぐ」だけでは粒度が分かりませんが、リリースノートをたどるとガードレールの中身が見えてきます。

• 1.2.1: ツール実行の上限とレート制御が、MCPのトップ画面の「Guardrails」セクションに移りました。UIから変更でき、splunkdの再起動は要りません。Splunk AI Assistantの呼び出しがタイムアウトするまでの秒数も、ここで設定できます
• 1.3.0: Guardrailsタブに「Allowed SPL Commands」が加わり、管理者がMCP経由で実行を許すSPLコマンドを追加・削除できます。管理者以外のユーザーには、Splunk Native・Custom・Builtinのコマンドが読み取り専用で表示されます
• 1.3.0: ツールごとのレート制限は、全体のレート制限を超えて設定できません。全体の制限も、既存のツール別制限を下回る値にはできません
• 1.2.1: MCP Telemetry Dashboardで、誰がどの認証方法でMCPを使い、どれだけ消費し、どこでエラーが出ているかを確認できます

SPLコマンドの制限を設定ファイルの手作業で管理していた管理者は、1.3.0以降は新しい画面の内容を見直すよう、リリースノートに注意書きがあります。Claudeに調査を任せる前に、許可するSPLコマンドの範囲を決めておく設計が取れる、ということです。

SSL設定

READMEによると、SSL検証の有無はmcp.confで切り替えられます(1.0.0で追加)。

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

Splunk側のssl_verifyと、クライアント側のNODE_TLS_REJECT_UNAUTHORIZEDは別の設定項目です。1.0.1では、証明書エラー時にホスト名が不正になるバグが修正されています。

よくあるつまずき

• Authorizationヘッダーを付け忘れる: 管理ポートへの直接接続もクライアント設定も、READMEの例はすべてAuthorizationヘッダー付きなので、初期化が失敗したらまず付け忘れを疑います
• ロールにケイパビリティが付いていない: 1.2.1以降は、mcp_tool_adminが無いと管理系の操作で上記のエラーメッセージが出ます。接続はできるのに操作だけ失敗するときは、authorize.confのロール設定を見ます
• 管理ポートに届かない: /services/mcpは管理ポート(既定8089)の下にあります。検索用のポートしか開けていないネットワークでは接続できません
• Splunk AI Assistantの前提を満たしていない: データ探索ツールにはAI Assistant 2.2.0以降とAgent Modeが必要です(2.0.0のリリースノート)
• 期間を書かずに依頼する: 2.0.0以降、期間なしの検索は直近6時間が対象です

実務での使い方の例

READMEは、利用場面を3つ挙げています。

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

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

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

バージョン履歴

導入前に決めておくこと

本番のSplunkに接続する前に、次の2点を決めておくと事故を防げます。

1. トークンの権限範囲: そのトークンでSplunk上から見えるインデックス・保存済み検索が、AIに調べさせたい範囲と一致しているか
2. ロール設計: 新しいロールを作るか、既存ロールにケイパビリティを足すか

ログに加えてメトリクスやクラスタ操作も調べたいなら、PrometheusのMCPサーバーやKubernetes MCPサーバーを別のMCPサーバーとして並べる構成があります。それぞれのRBACを保ったまま、調査範囲を広げられます。

まとめ

Splunk 9.3以降なら2.0.0のリリースノートを、8系や9.2以前ならREADMEを正として読みます。依頼文には、検索してほしい期間を必ず書いておきます。