Litmus Edge MCPとClaudeをつないで産業機器のデータを読む

Litmus Edge MCPサーバーは、工場や設備の現場に置いたエッジ機器(Litmus Edge)の状態やタグの値を、Claudeから自然言語で読めるようにするMCPサーバーです。Litmus Automationが提供しており、デバイスの設定・監視・管理を担うサーバーです。

SaaSのコネクタと違い、サーバーを自分のネットワーク内で動かす点が出発点です。この記事では、サーバーの起動、Claude DesktopとClaude Codeへの登録、読み取りに使うツール、書き込み系ツールの扱いを順に説明します。

Litmus MCPコネクタは何を仲介するのか

Claudeのコネクタ一覧には「Litmus MCP」が載っています。説明は「Litmus MCPサーバー経由でLitmus Edgeの産業機器につなぐ」というもので、Anthropic verifiedの表示があり、追加時期は2026年8月です。

注意したいのは、コネクタがクラウド上の接続先ではなく、自分で動かすLitmus MCPサーバーへの橋渡しだという点です。コネクタの説明には、Claude Desktopを自分のネットワーク上のサーバーにつなぐ拡張であり、認証情報はOSのキーチェーンに保存されてそのサーバーにだけ送られる、とあります。サーバー側の準備が先に要ります。

つながる先で、できることは次の4種類です。

ツールは13カテゴリで62個あります。カテゴリにはDeviceHubのデバイスとタグ、NATSトピック、InfluxDBの時系列、デジタルツイン、Dockerコンテナ管理、パケットキャプチャ、Litmus Edge Manager(LEM)などが含まれます。

サーバーを起動する(Docker)

最短はDockerです。クイックスタートは次のとおりです。

docker run -d --name litmus-mcp-server \
  -p 8000:8000 \
  ghcr.io/litmusautomation/litmus-mcp-server:latest

起動すると、8000番ポートで2つのエンドポイントが開きます。

• http://<host>:8000/mcp: Streamable HTTP。現行のMCP仕様で、推奨されている接続先
• http://<host>:8000/sse: HTTP+SSE。古いクライアント向けに残されている

このサーバーはlinux/AMD64向けにビルドされています。Apple SiliconなどARM64のマシンで動かすときは、--platform linux/amd64 を付けます。

接続先のエッジ機器に用意するもの

サーバーを立てただけでは、機器のデータはまだ読めません。ツールの利用上の注意にある前提を、読みたいデータ別に並べると次のとおりです。

Litmus Edge自体への接続は、EDGE_URL(https://を含むベースURL)と、Litmus Edgeで発行したOAuth2の EDGE_API_CLIENT_ID / EDGE_API_CLIENT_SECRET で行います。

Claude Desktopに登録する(STDIO)

Claude DesktopはSTDIOで接続します。リポジトリをcloneして依存を入れ、設定ファイルにサーバーを書く流れです。

git clone https://github.com/litmusautomation/litmus-mcp-server.git
cd litmus-mcp-server
uv sync

設定ファイルの場所はOSごとに決まっています。

• macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
• Windows: %APPDATA%\Claude\claude_desktop_config.json
• Linux: ~/.config/Claude/claude_desktop_config.json

コネクタ経由か、手動設定か

冒頭で紹介したマーケットプレイスのコネクタは、Claude Desktopから自前のサーバーへつなぐ拡張で、認証情報はOSのキーチェーンに保存されます。ここで説明する claude_desktop_config.json の手動設定は、それとは別の経路です。サーバーのURLや認証情報の入力欄がコネクタ側のどこに出るかは、コネクタのページに記載がありません。どちらの経路でも、先にサーバーを動かしておく点は変わりません。手動設定は、次の形で書きます。

{
  "mcpServers": {
    "litmus-mcp-server": {
      "command": "/path/to/.venv/bin/python3",
      "args": ["/absolute/path/to/litmus-mcp-server/src/server.py"],
      "env": {
        "ENABLE_STDIO": "true",
        "PYTHONPATH": "/absolute/path/to/litmus-mcp-server/src",
        "EDGE_URL": "https://<LITMUSEDGE_IP>",
        "EDGE_API_CLIENT_ID": "<oauth2_client_id>",
        "EDGE_API_CLIENT_SECRET": "<oauth2_client_secret>",
        "NATS_PASSWORD": "<access_token_from_litmusedge>",
        "INFLUX_USERNAME": "<datahub_username>",
        "INFLUX_PASSWORD": "<datahub_password>"
      }
    }
  }
}

ENABLE_STDIO を "true" にするのが落とし穴です。これが無いとサーバーはHTTPモードで起動し、標準入出力に一切応答しません。Claude Desktopは60秒の初期化タイムアウトのあとで接続を切ります。「サーバーが緑にならない」ときは、まずこの値を確認します。

NATS_SOURCE、NATS_PORT、INFLUX_HOST、INFLUX_PORT は省略できます。省略すると、EDGE_URL のホストから nats://<edge-host>:4222 と http://<edge-host>:8086 を導出し、そのことをツールの応答に書き添えます。データ系統がEdgeのWeb UIと別のアドレスにあるときだけ書けば足ります。

Claude Codeに登録する(HTTP)

Claude Codeには、Docker上のHTTPサーバーを type: "http" でつなげます。READMEの例では、次のJSONを ~/.claude/mcp.json に置いています。認証情報はヘッダーで渡し、値は環境変数から展開します。

{
  "mcpServers": {
    "litmus-mcp-server": {
      "type": "http",
      "url": "http://localhost:8000/mcp",
      "headers": {
        "EDGE_URL": "${EDGE_URL}",
        "EDGE_API_CLIENT_ID": "${EDGE_API_CLIENT_ID}",
        "EDGE_API_CLIENT_SECRET": "${EDGE_API_CLIENT_SECRET}",
        "NATS_PASSWORD": "${NATS_PASSWORD}",
        "INFLUX_USERNAME": "${INFLUX_USERNAME}",
        "INFLUX_PASSWORD": "${INFLUX_PASSWORD}"
      }
    }
  }
}

設定ファイルには ${EDGE_API_CLIENT_SECRET} のように変数名だけを書き、実際の値はシェルの環境変数に置く形です。シークレットをリポジトリに載せずに済むため、チームで設定を共有するときに向きます。MCPサーバーの登録や認証の扱いはClaude Code側の仕組みなので、保存先のエラーで詰まったときはMCPのstored credentialsエラーの記事も参照してください。

読み取りから始め、書き込みは線を引く

ツール表には、読むだけのものと、機器の状態を変えるものが混在しています。次のように分けられます。

• 読み取り系: get_devicehub_devices、get_current_value_of_devicehub_tag、list_influxdb_measurements、get_system_events など
• 作成・更新系: create_devicehub_device、create_devicehub_tag、update_devicehub_tag、run_docker_container_on_litmusedge、start_packet_capture など
• 削除系: delete_devicehub_tag(表に「Destructive」とある)

さらに、litmus_sdk_discover / litmus_sdk_read / litmus_sdk_write の3つが、約550関数のSDK全体への入口です。litmus_sdk_read は、関数名の最後の区切りがGet・List・Browse・Describe・Read・Search・Find・Query・Countで始まる読み取り専用のものしか受け付けません。それ以外は litmus_sdk_write を通り、呼び出しごとに user_approved 引数が必須です。この引数は、ユーザーが関数名と引数を承認したあとにだけ、アシスタントが設定してよいとされています。

現場の機器につなぐなら、最初はClaude側のツール許可で読み取り系だけを通し、作成・削除・SDK書き込みは都度確認にしておく運用が考えられます。ClaudeがタグのEdge側設定やDockerコンテナを動かせる、という性質そのものが、読み取り用途とは別のリスクです。

読み取りだけで試す問いかけ例

接続できたら、次のような依頼から始められます。ツールの選択はClaudeが行います。

設定済みのデバイスの接続状態を一覧にして。stale や no_data のものを先頭に。

get_device_connection_status は、InfluxDBのハートビートをもとにconnected / stale / no_dataを返すツールです。履歴系と同じく8086番の疎通が前提です。時系列の傾向を聞くなら、get_tag_statistics が平均・最小・最大・標準偏差と、平均±2σの基準範囲を返します。

TLS証明書とWeb UIで知っておくこと

エッジ機器は自己署名証明書を使うことが多く、その扱いは細かく決まっています。

VALIDATE_CERTIFICATE の既定は true で、証明書を検証します。証明書が拒否されたときだけ、サーバーは検証なしで同じツールをもう一度実行して結果を返します。このとき応答に、ホストを名指しした tls_warning が付きます。パスワード誤りや接続拒否、タイムアウトでは再試行しないので、認証情報が検証なしの経路に流れることはありません。

警告を出さずに検証を外したいときは、自己署名と承知のうえで VALIDATE_CERTIFICATE=false を明示します。値が flase のような打ち間違いだった場合は、検証を外す意思表示とは読まず、検証する側に倒れます。

ほかにブラウザのチャット画面(Web UI)もあります。9000番ポートで公開し、Anthropic・OpenAI・Geminiのキーのいずれかを使います。ただしWeb UIにはログインがなく、LLMのAPIキーとLitmus Edgeの認証情報を保存するため、信頼できるネットワークにだけ公開するよう注意書きがあります。MCPクライアントが使うのは8000番(/mcp)だけです。

似た構成との使い分け

Litmus Edgeのように、自分の環境にMCPサーバーを置いて社内のデータを引く構成は、ほかにもあります。クラウドのデータ基盤なら、Dremio・Starburstのレイクハウス連携やCData Connect AIの複数データソース連携がOAuthで済む構成です。AWSの権限管理と組み合わせる例はAWS MCPサーバーの連携記事にあります。

産業機器の場合は、読むデータが製造ラインの現在値であることと、サーバーがOT側のネットワークに近い場所に要ることが違います。

まとめ

Litmus Edge MCPサーバーは、Claudeのコネクタ一覧に載っていても、サーバー自体は自前で動かす構成です。試す順番としては、Dockerで8000番を立て、DeviceHubのデバイス一覧とタグ値の読み取りまでを確認し、そのあとでNATSトークンとInfluxDBの許可を足して履歴へ進むと、どこで詰まったかを切り分けやすくなります。書き込み系ツールの許可は、読み取りが安定してから別に決めれば足ります。