Claude Media
RabbitMQのMCPサーバーでClaudeからキューとExchangeを操作する
Claude CodeMCPClaude連携チュートリアル

RabbitMQのMCPサーバーでClaudeからキューとExchangeを操作する

AWSのamazon-mq組織が公開するmcp-server-rabbitmqを使い、キュー深さの監視やデッドレターキュー調査を自然言語でClaudeに任せる手順とセキュリティ設計を扱います。

読了目安 約12分

RabbitMQ MCPサーバーとは何か

mcp-server-rabbitmqは、RabbitMQブローカーの管理・運用操作をMCP経由でAIエージェントに公開するサーバーです。GitHubのamazon-mqorganization配下でApache-2.0ライセンスで公開されているPython製ツールで、Amazon MQ専用ではなく、自前でホストしているRabbitMQブローカーを含む汎用のRabbitMQ管理を対象にしています。README自体に「AWSの公式サポート対象」であるとの明記はなく、AWSのorganizationから配布されている汎用RabbitMQ向けOSSという体裁です。

このMCPサーバーが解決するのは、キューの詰まりやデッドレターキュー(処理に失敗したメッセージの退避先)の調査といった、RabbitMQ運用でありがちな「管理画面を何度も行き来して原因を探す」作業です。31個(v4)または61個(v3)のツールに加えて、複数ツールを組み合わせた「Skills」という16種類の定型ワークフローが用意されており、単発のツール呼び出しより一段抽象化された調査を自然言語の依頼だけで進められます。

導入前に確認すること

  • Python 3.10以上(uv経由での実行が推奨)
  • 接続先のRabbitMQブローカー(AMQPエンドポイントとManagement APIの両方への到達性)
  • Claude CodeまたはClaude Desktopなど、MCPクライアントとして動く環境
  • 書き込み系操作(キュー作成・削除・rebalanceなど)を使う場合は、ブローカー側のRabbitMQユーザーに相応の権限があること

パッケージはamq-mcp-server-rabbitmqという名前でPyPIに公開されており、pip installまたはuvxでそのまま実行できます。

v3とv4、どちらを選ぶか

このサーバーはツールレイアウトが異なる2つのバージョン系列を同じリポジトリから配布しています。

バージョンツール数呼び出し方向いている場面
v3(3.x系)ツール数61(操作ごとに1ツール)呼び出し方rabbitmq_broker_list_queuesのような専用ツール名向いている場面v2系からの既存プロンプト・連携をそのまま使いたい
v4(4.x系)ツール数31(enumベースのディスパッチャ)呼び出し方queues(action="list")のようにactionを渡す向いている場面ツール説明文のトークン消費を抑えたい、--tool-groupsで必要な機能だけ絞りたい

v4はツール説明文のトークン量をおよそ2,300から900程度まで削減できるとREADMEに記載されています(この数値はリポジトリ側のツール定義を基準にした計測で、実際のクライアントやモデルのトークナイザーによって変わります)。パッケージを最新化しても既定ではv3互換の挙動のままなので、--v4フラグを明示しない限り既存の連携が壊れることはありません。移行期は--v1-compatを付けるとv4のツールに加えてv3の旧ツール名もエイリアスとして登録されるため、プロンプト側の書き換えを急がずに済みます。

Claude Codeに接続する

pip install amq-mcp-server-rabbitmq

Claude Desktopの設定ファイルにv4モードで追加する場合は次の形です。

{
  "mcpServers": {
    "rabbitmq": {
      "command": "uvx",
      "args": [
        "amq-mcp-server-rabbitmq@latest",
        "--v4",
        "--allow-mutative-tools"
      ]
    }
  }
}

接続先ブローカーの情報は、セッション内でconnectツールを呼ぶ方法と、環境変数RABBITMQ_AMQP_ENDPOINTで起動時に接続する方法の2通りがあります。後者は、MCPホストがセッションやツール呼び出しのたびにサーバープロセスを再起動する構成(アグリゲータやプロキシ経由の利用)で特に有効です。接続状態がプロセスと一緒に消えてしまい、毎回「アクティブなブローカーがありません」というエラーになるのを避けられます。

{
  "mcpServers": {
    "rabbitmq": {
      "command": "uvx",
      "args": ["amq-mcp-server-rabbitmq@latest", "--v4"],
      "env": {
        "RABBITMQ_AMQP_ENDPOINT": "amqps://admin:pass@broker.example.com:5671"
      }
    }
  }
}

エンドポイントURIのスキームがTLSとデフォルトポートを決めます。amqpsはTLS接続でポート5671、amqpは平文でポート5672です。認証情報に@や/のような予約文字を含む場合はパーセントエンコードが必要で、たとえばp@ss/wordというパスワードはp%40ss%2Fwordと書きます。

キュー深さの監視とデッドレターキュー調査

読み取り専用のツール群だけでも、日常的な運用監視の大半はカバーできます。queue_metrics_analysisスキルはget_queue_infoが返すpublish/deliverレートとバックログの推移を解釈し、「このキューは処理が追いついていない」といった判断材料に変換します。resource_headroom_checkはノードのメモリ・ディスクの余裕率を計算し、アラーム発報までの時間を見積もります。

デッドレターキュー(DLQ)調査は特に強力です。trace_dead_letter_chainは各キューのx-dead-letter-exchange引数を辿り、DLXの接続関係全体をマップします。inspect_dead_lettersは実際にDLQ内のメッセージを覗き、x-deathヘッダーから元のキュー名や失敗理由を取り出します。dlq_summaryはそれをさらに集計し、どのキューからどんな理由でどれだけデッドレターが発生しているかを一覧化します。管理画面でメッセージを1件ずつ開いてx-deathヘッダーを読み解く作業を、自然言語の依頼1つに置き換えられる部分です。

  • 「注文キューのデッドレターを要約して、どのキューが原因になっているか教えて」
  • 「クラスタ全体でディスク使用率が閾値に近いノードはある?」
  • 「exchange-ordersからrouting key order.created を投げたら、どのキューに届く?」(trace_message_routeスキル)

書き込み操作は既定で無効

キューの作成・削除やvhost管理、接続の強制切断といった変更を伴う操作は、--allow-mutative-toolsフラグを明示的に渡さない限り一切ロードされません。読み取り専用のツール(readグループ)とヘルスチェック(healthグループ)は常にロードされる一方、mutative(CRUD操作)とmigration(ブルーグリーン移行関連)は許可フラグ側のグループです。

  • TLSが既定: 接続はデフォルトでuse_tls=True・ポート5671を使い、TLSを使わない接続にはレスポンス内で警告が付く
  • SSRF対策: プライベートIPやループバックアドレスへの接続はホスト名検証でブロックされる
  • 認証情報のマスキング: ブローカー定義をエクスポートする際、パスワードなど機微な項目は自動的に取り除かれてからエージェントに返る
  • 影響の大きい操作もmutativeグループ扱い: close_connection・rebalance_queues・set_permissionsは影響の大きい操作としてmutativeグループに置かれ、--allow-mutative-toolsなしでは読み込まれない

本番ブローカーに繋ぐ場合は、まず--allow-mutative-toolsを付けずに調査・監視用途だけで運用し、実際にキューやポリシーの変更をエージェントに任せたくなった段階でフラグを追加する、という順番が安全です。

migrationツールグループを有効にすると、ブルーグリーン移行(新旧2つのブローカーを並行稼働させて切り替える手法)向けのスキルも使えます。pre_flight_migration_checkは移行元・移行先の両ブローカーでアラーム状態を確認したうえで定義を比較し、切り替えて良いかを判定します。migrate_definitionsは変換ルールを適用しながらエクスポートとインポートを1つの依頼で実行します。手作業で両ブローカーの管理画面を行き来しながら定義をエクスポート・インポートする作業を、事前チェックごと自然言語の依頼に置き換えられる部分です。

チームで共有するリモートサーバーとして動かす

ここまでのuvx起動は、Claude Desktopなどが子プロセスとして起動するstdio接続を前提にしています。チームで1つのサーバーを共有したい場合は、--httpフラグでStreamable HTTPトランスポートに切り替えられます。

uvx amq-mcp-server-rabbitmq@latest --v4 --http --server-port 8888 \
  --http-auth-jwks-uri https://your-idp.example.com/.well-known/jwks.json \
  --http-auth-issuer https://your-idp.example.com/ \
  --http-auth-audience rabbitmq-mcp

HTTPモードでは、社内のIdP(IDプロバイダ)が発行するJWTをJWKS経由で検証する仕組みが組み込まれています。--http-auth-jwks-uriはHTTPS以外のURIを渡すとサーバー側が起動を拒否する設計になっており、トークン検証をバイパスされる経路をあらかじめ塞いでいます。--http-auth-required-scopesで特定のスコープを持つトークンだけを受け付けるよう絞ることもできます。個人のuvx起動と違い、リモートサーバー化した瞬間にネットワーク上の誰かがブローカーへアクセスできる経路が生まれるため、認証設定を省略しての運用は避けてください。

よくあるつまずき

  • 「アクティブなブローカーがありません」と毎回言われる: MCPホストがセッションごとにプロセスを再起動する構成では、connectツールでの都度接続だと状態が消えます。RABBITMQ_AMQP_ENDPOINT環境変数を設定し、起動時接続に切り替えます
  • v3向けに書いたプロンプトがv4で動かない: v4は--v4を付けた瞬間にツール名がrabbitmq_broker_list_queuesのような形式からqueues(action="list")のようなディスパッチャ形式に変わります。移行期は--v1-compatでv3の旧ツール名も併存させ、プロンプトの書き換えを段階的に進めます
  • 書き込み系ツールを頼んだのに動かない: --allow-mutative-toolsを渡していないと、キュー作成やポリシー変更のツールはそもそもロードされません。意図的な安全策なので、必要な場面だけ明示的に付けます
  • 認証情報に含めた記号でエンドポイントURIが壊れる: パスワードに@や/を含む場合はパーセントエンコードが必須です。エンコードし忘れるとホスト名やポートの解釈がずれて接続に失敗します
  • --management-portを指定したのにTLSで繋がらない: --management-portはManagement APIの既定ポート(TLS時443、非TLS時15672)を上書きするだけです。TLSを使うかどうかはAMQPエンドポイントのスキーム(amqpsかamqp)側で決まる点を混同しないようにします

まとめ

mcp-server-rabbitmqは、AWSのamazon-mqorganization配下でApache-2.0ライセンスで公開されている、AWS専用ではない汎用RabbitMQ向けのMCPサーバーです。既定では読み取り専用で動き、キュー監視やデッドレターキュー調査は--allow-mutative-toolsを付けなくても始められます。本番ブローカーに繋ぐときは、まず監視用途で様子を見てから、必要になった時点で書き込み権限を追加する順序が安全です。

MCPの基礎から確認したい場合はMCPとは何か、claude mcp addのスコープや認証の詳細はClaude Code MCP設定ガイド、ツールごとの許可・拒否ルールを細かく設定したい場合はClaude Code MCP権限ルールにまとめています。セルフホスト環境からMCPサーバーを届ける経路の選び方はClaude Codeセルフホスト環境にMCPサーバーを届ける3つの経路も参考になります。

この記事を共有:XはてブLinkedIn

関連する記事

Claude Code をもっと見る →