Nomad MCPサーバーでジョブとクラスタ状態をClaudeに監視させる

HashiCorpはNomad向けの公式MCPサーバーを持っていません。同じHashiCorp製品でもTerraformには公式のMCPサーバーがありますが、Nomadは非公式のコミュニティ実装が実質的な選択肢です。中でもkocierik/mcp-nomadはGo製のネイティブバイナリで、npm経由の配布とnpxでの即時起動に対応しています。本記事はこのMCPサーバーをClaude Codeに追加する手順と、ジョブ・アロケーション・ACLまで書き込み系のツールを大量に持つ以上、接続前にNomad側のACLトークンを絞る必要がある理由を扱います。

Nomad MCPサーバーとは何か

kocierik/mcp-nomadはNomadのHTTP API(/v1/)にGoから直接つなぐMCPサーバーです。kubectlのようなCLIをラップするのではなく、Nomadクライアントを内部に持ち、MCPツール呼び出しをNomad APIリクエストへ変換します。GitHubスター数は59まで伸び、直近のコミットも活発に続いています。同種のコンテナオーケストレーター向けMCPサーバーと同様、単一バイナリで動く点が特徴です(後述の使い分けで詳しく比較します)。

配布形態は3つあります。

トランスポートはstdio(既定)・sse・streamable-httpの3種類に対応します。Claude Codeやローカルのデスクトップクライアントからはstdioで十分ですが、複数人でMCPサーバーを共有したいならstreamable-httpで起動してHTTPエンドポイントとして公開できます。

Claude Codeに追加する手順

npxが使える環境なら、claude_desktop_config.json(またはClaude Codeの.mcp.json)に以下を追加するだけです。環境変数NOMAD_ADDR(NomadのHTTP APIアドレス)とNOMAD_TOKEN(ACLトークン)を先に用意してください。

{
  "mcpServers": {
    "mcp_nomad": {
      "command": "npx",
      "args": ["-y", "@kocierik/mcp-nomad"],
      "env": {
        "NOMAD_TOKEN": "${NOMAD_TOKEN}",
        "NOMAD_ADDR": "${NOMAD_ADDR}"
      }
    }
  }
}

npm install -g @kocierik/mcp-nomadでグローバルインストールした場合は、commandをnpxからmcp-nomadに差し替えるだけで同じ設定が使えます。設定を保存したらClaude Codeを再起動し、接続状態を確認します。

claude mcp list

mcp_nomadがConnectedと表示されれば準備完了です。動作確認だけなら、MCP Inspectorを経由してブラウザ上でツールを1つずつ呼び出せます。

npx @modelcontextprotocol/inspector npx @kocierik/mcp-nomad

NOMAD_ADDRの既定値はhttp://localhost:4646です。リモートクラスタに繋ぐ場合は必ず明示的に設定してください。TLSを使うクラスタ向けにはNOMAD_CACERT・NOMAD_SKIP_VERIFY・NOMAD_TLS_SERVER_NAMEの3つの環境変数も用意されています。マルチリージョン構成ではNOMAD_REGIONを、既定namespace以外を使う場合はNOMAD_NAMESPACEを指定します。

設定ファイルを直接編集せず、コマンド1つで追加したい場合はclaude mcp add-jsonも使えます。MCPサーバーの追加コマンドの構文やスコープの使い分けそのものはClaude Code MCP設定ガイドにまとめているので、ここではenv付きの実例だけを示します。

claude mcp add-json mcp_nomad \
  '{"command":"npx","args":["-y","@kocierik/mcp-nomad"],"env":{"NOMAD_TOKEN":"'"$NOMAD_TOKEN"'","NOMAD_ADDR":"'"$NOMAD_ADDR"'"}}' \
  -s user

-s userを付けるとすべてのプロジェクトで使えるようになります。特定のリポジトリだけで使うなら-s local(既定)、チームで共有したいなら.mcp.jsonに書いて-s projectにします。

運用監視で実際に使う指示例

接続後は、自然言語でジョブやクラスタの状態を聞くだけでツールが呼ばれます。運用監視でよく使う指示はおおむね次のパターンに収まります。

• 「web-apiジョブの現在のステータスを教えて」→ get_jobでジョブの状態・タスクグループ構成を取得
• 「web-apiジョブの直近のアロケーションで失敗しているものはある?」→ get_job_allocationsとget_allocationを組み合わせて異常なアロケーションを絞り込み
• 「失敗しているアロケーションのログを見せて」→ get_allocation_logsでstdout/stderrを取得
• 「クラスタのリーダーノードとピア一覧を教えて」→ get_cluster_leaderとlist_cluster_peersでクラスタ全体の健全性を確認
• 「prodnamespaceのジョブを一覧して、評価待ちのものだけ抜き出して」→ list_jobsとget_job_evaluationsの組み合わせ

いずれも読み取り系ツールだけで完結する使い方です。読み取り専用のACLトークンを渡しておけば、こうした監視作業を書き込み操作の心配なく任せられます。

40近いツールでジョブとクラスタの何を扱えるか

このMCPサーバーが登録するツールは、確認できただけで9カテゴリ・約40種類に及びます。

読者が「監視だけしたい」と考えていても、このサーバーは監視専用ではありません。ジョブの投入・停止・スケール、ノードのドレイン、ACLトークンの発行・削除まで、Nomadクラスタの状態を変更するツールが標準で有効になっています。

なお、Sentinelポリシー系のツール(list_sentinel_policies・create_sentinel_policy等)はNomad Enterprise限定の機能に対応するツールです。Nomad OSS(コミュニティ版)クラスタに接続した場合、これらのツールを呼んでもAPI側がガバナンス機能自体を持たないため空振りします。ACL・ジョブ・ノード・アロケーション系のツールはOSS・Enterprise問わず動作します。

既定でread-onlyではない — ACLトークンを絞る

ソースコードを確認すると、このMCPサーバー自体に--read-onlyのようなフラグは存在しません。main.goが受け付けるフラグはtransport・portの2つだけで、書き込み系ツールを無効化する仕組みはサーバー側にありません。つまり、渡したNOMAD_TOKENの権限がそのままMCPツールの実行権限になります。

制御はNomad本体のACLポリシーで行います。namespaceブロックにpolicy = "read"を指定すれば、そのnamespaceに対して読み取り専用のトークンを発行できます。

namespace "default" {
  policy = "read"
}

もっと細かく絞りたい場合は、list-jobs・read-job・read-logsのような個別capabilityだけを許可します。submit-job(投入・更新・停止)やscale-jobを外せば、ジョブに対する書き込みツールを呼んでもNomad側のAPIが403を返し、実害を防げます。ACLの発行自体にはnomad acl token createとnomad acl policy applyが必要です。個人の開発クラスタで一時的に検証するだけなら管理者トークンでも実害は小さいですが、共有クラスタやCI環境に接続する場合は、この読み取り専用ポリシーを先に発行してからNOMAD_TOKENに渡してください。

Kubernetes MCPサーバーとの使い分け

コンテナオーケストレーターのMCPサーバーとしては、Kubernetes MCPサーバーも選択肢に挙がります。両者は思想が異なるので、扱う基盤で選び分けます。

Kubernetes MCPサーバーは--read-onlyと--toolsetsという2段構えの絞り込みをサーバー自身が持っています。Nomad MCPサーバーにはこの機構が無いため、絞り込みの責任はNomad側のACLポリシー設計に一本化されます。裏を返せば、Nomadを使っているチームはすでにACLポリシーの運用に慣れていることが多く、既存のポリシーをそのままMCP用トークンに割り当てるだけで済みます。

よくあるつまずき

• streamable-httpで起動したのにInspectorが繋がらない: デフォルトのURLはhttp://localhost:8080/mcpです。/sseではないので、-transport=sseと-transport=streamable-httpでパスを間違えやすい箇所です
• リモートクラスタに繋がらない: NOMAD_ADDRの既定値はlocalhost:4646です。環境変数を明示的に設定し忘れると、ローカルにNomadが無い環境では接続エラーになります
• 一部の操作だけInvalid argumentsで失敗する: NomadClient.MakeRequestは内部の許可リストに含まれないパスを拒否する実装になっています。個別ツール(StopAllocationなど型付きのヘルパー)経由なら問題なく動きますが、想定外のエンドポイントを直接叩こうとすると弾かれます
• ACLを絞ったらツールがエラーを返すようになった: 想定どおりの挙動です。Nomad APIが403を返しているだけで、MCPサーバー側のバグではありません。必要なcapabilityを1つずつ足していくのが安全です
• Sentinel系のツールを呼んでも何も返らない: OSSクラスタに接続している可能性があります。Sentinelポリシーの作成・参照はNomad Enterpriseの機能なので、OSS環境では空の結果かエラーになります

よくある質問

Nomad MCPサーバーはAnthropic公式のプロダクトですか

いいえ。kocierik個人が開発・メンテナンスしているOSSで、Anthropicはもちろんhashicorp orgとも無関係です。Claude Codeの標準的なMCP追加手順(claude mcp add-jsonまたは設定ファイル編集)で繋げる、サードパーティ製のMCPサーバーの1つです。

Nomad Enterpriseでなくても導入する価値はありますか

あります。Sentinelポリシー系のツール以外は、ジョブ・アロケーション・ノード・ACL・namespace・volumeの操作を含めてすべてNomad OSSで動作します。約40種のツールのうち、Enterprise限定で機能しないのはSentinel関連の数ツールだけです。

Terraform用に発行しているHCPアカウントの認証情報を流用できますか

できません。NomadとTerraformはHashiCorp製品としては近い関係にありますが、認証はそれぞれ独立しています。Nomad MCPサーバーにはnomad acl token createで発行したNomad専用のACLトークンが必要です。

まとめ

HashiCorpはNomad向けの公式MCPサーバーを提供していません。kocierik/mcp-nomadはGo製ネイティブバイナリでnpx起動にも対応した、現状もっとも現実的な選択肢です。ただしジョブの投入・停止・スケール、ノードのドレイン、ACLトークンの発行・削除まで書き込み系ツールを標準で持つため、MCPサーバー自身のread-onlyフラグではなく、Nomad側のACLポリシーでNOMAD_TOKENの権限を先に絞ってから接続します。監視用途に限定したいチームほど、この一手間を省略しないことが重要です。他のMCPサーバーとどう組み合わせるかはおすすめMCPサーバー10選も参考になります。