ClaudeとAutomoxを連携する方法 — パッチ状況と違反端末を会話で引く
AutomoxコネクタでClaudeからデバイス・パッチ・ポリシーを照会する手順です。133ツールのうち読み取り85・書き込み48の内訳、読み取り専用モード、月次パッチ報告の下書きへの使い方をまとめます。
Automoxコネクタでできること
Automoxコネクタは、エンドポイント管理サービスAutomoxの公式MCPサーバーをClaudeにつなぐ仕組みです。ディレクトリのページには「Anthropic verified」の表示があり、掲載は2026年8月です。提供元はAutomox自身で、ページの説明は「Automoxのコンソールを自然言語で操作する」となっています。
つなぐと、端末の一覧、パッチの適用状況、ポリシーの実行結果、コンプライアンスの状況を会話で引けます。ツールは133個、領域は18に分かれます。内訳は次のとおりです。
Automox MCPサーバーの規模
ツール総数
133
18領域
読み取り
85
状態を変えない
書き込み
48
変更・削除・実行
ワークフロープロンプト
6
調査・監査の定型手順
「書き込み48」が重要です。照会だけのつもりで接続しても、設定を変えなければ書き込み系ツールも使える状態になります。次節以降は、この前提で組み立てています。
接続の前に決める2つのこと
接続方法は、使うクライアントで変わります。READMEの整理は次のとおりです。
| 使うもの | 接続の形 | 認証 |
|---|---|---|
| Claude Desktop | 接続の形ディレクトリのコネクタ、または拡張機能(.mcpb) | 認証AutomoxのAPIキー |
| Claude Code | 接続の形claude mcp add でローカル起動、またはホスト型サーバー | 認証AutomoxのAPIキー |
ディレクトリのページには「Claude Desktop Extensionとして提供」とあります。つまりローカルで動くサーバーで、認証はOAuthでなくAPIキーです。Automoxが運営するホスト型サーバー(https://console.automox.com/api/mcp)もありますが、Claude Desktopの組み込みカスタムコネクタはOAuthを前提にするため、READMEによれば今は使えません。Desktopで使うなら、ディレクトリのコネクタか拡張機能です。
もう1つはAPIキーの種類です。Automoxには組織単位のキーとアカウント全体のキーがあり、READMEは組織単位を推奨しています。アカウント全体のキーは、高度なデバイス検索系のツールで403が返ることがあると書かれています。照会で403が出て、他の読み取りは通るなら、権限よりキーの種類を疑う場面です。
Claude Desktopでつなぐ手順
READMEが示す手順は、アプリを離れずに済む形です。
Claude Desktopでの接続
- 1
キーを用意する
Automoxコンソールの「Settings > Secrets & Keys」で組織単位のAPIキーを作ります。同じ画面でアカウントのUUIDも確認します。
- 2
コネクタを探す
Claude Desktopの「Settings > Connectors」で「Automox」を検索して追加します。
- 3
認証情報を入れる
APIキー、アカウントUUID、任意で組織IDを入力します。組織IDは必須ではありませんが、ほとんどのツールが必要とします。
拡張機能(.mcpb)をGitHubのReleasesから入れる方法もあります。ファイルをSettings > Extensionsの画面にドラッグし、同じ3つの値を入力します。
Claude Codeでつなぐ手順
Claude Codeからは、READMEのコマンドでローカルサーバーを追加します。認証情報は .env に置きます。
claude mcp add automox-mcp uvx -- \
--env-file /path/to/.env automox-mcp.env には AUTOMOX_API_KEY・AUTOMOX_ACCOUNT_UUID・AUTOMOX_ORG_ID の3つを書きます。キーをリポジトリにコミットしないよう、.env は管理対象の外に置きます。
ホスト型サーバーを使う場合は、HTTPで追加してBearerトークンにAPIキーを渡します。
claude mcp add --transport http automox \
https://console.automox.com/api/mcp \
--header "Authorization: Bearer YOUR_AUTOMOX_API_KEY"どちらもAutomoxのキーが持つ権限で動きます。READMEは、ホスト型でも「コンソールやAPIと同じ権限が適用され、MCPはあなたとして動く」と説明しています。Claude CodeでAutomoxを触るときは、このキーの権限がそのまま作業範囲になります。
照会専用に絞る — 読み取りモードと権限
端末の削除、ポリシーの変更、パッチの即時適用はAutomoxの本番環境に直結します。月次報告のための照会なら、書き込みは不要です。絞る方法は3層あります。
書き込みを止める3つの層
サーバー側の読み取り専用
AUTOMOX_MCP_READ_ONLY=trueで書き込みツールを登録しません。85のツールだけが残ります。ローカルのサーバーが対象で、READMEはホスト型には適用されないと書いています。モジュールの絞り込み
AUTOMOX_MCP_MODULES=devices,policiesのように、読み込む領域を限れます。読み取り専用と併用できます。既定で閉じた危険操作
apply_remediation_actionsやdelete_deviceは、書き込みモードでも既定で無効です。専用の環境変数で明示的に許可しない限り使えません。
Claude Code側でも、権限ルールで止められます。MCPツールは mcp__<サーバー名>__<ツール名> の形で指定でき、denyルールは許可より優先されます。たとえば次のように書くと、端末へのコマンド実行と削除、ポリシー変更が呼び出せなくなります。
{
"permissions": {
"deny": [
"mcp__automox-mcp__execute_device_command",
"mcp__automox-mcp__delete_device",
"mcp__automox-mcp__apply_policy_changes"
]
}
}サーバー名は claude mcp add で付けた名前です。上の例は前述のコマンドの automox-mcp に合わせています。READMEは、各ツールに readOnlyHint と destructiveHint の注釈を付けているとも書いています。クライアントはこれを確認ダイアログに使えます。ただしAutomoxの権限そのものを絞るほうが確実です。照会用に、読み取り中心のロールを持つキーを分けて使う運用が考えられます。
聞けることと、対応するツール
READMEには、聞き方の例と動作の対応表があります。情シスの定例業務に近いものを抜き出します。
| 聞き方の例 | 動作(READMEの記載) |
|---|---|
| Patch Tuesdayに間に合っているか | 動作(READMEの記載)未適用パッチ、承認待ち、ポリシーのスケジュールを確認 |
| コンプライアンスの状況は | 動作(READMEの記載)適合率、非適合端末、健全性の内訳を返す |
| 注意が必要な端末は | 動作(READMEの記載)即対応が必要とフラグされた端末を出す |
| 30日以上見えていないWindows端末 | 動作(READMEの記載)高度なデバイス検索を構造化クエリで実行 |
「Patch Tuesday」と「コンプライアンス」は、それぞれ1回の呼び出しで複数の情報をまとめる複合ツールです。名前は get_patch_tuesday_readiness と get_compliance_snapshot です。複合ツールの各リストは、既定で10件に切られます。件数や合計は全件ぶんが返り、全件の明細が要るときは prepatch_report や noncompliant_report を呼ぶ設計です。
「ポリシー違反端末」を聞くときは、定義に注意が要ります。ツールの説明によると、非適合と数えるのは「ポリシーが修復を必要としている」端末だけです。保留中のパッチがあるだけの端末は、別の指標(devices_with_pending_policies)で数えます。管理職に報告する数字は、この区別を押さえてから出します。
月次パッチ報告の下書きに使う
Claudeに任せるのは、数字の取得と文章の整形です。判断と提出は人が行います。次のプロンプトは、読み取り専用の状態で使う想定の一例です。
Automoxで今月の状況を読み取り専用で確認し、
月次パッチ報告の下書きを作ってください。
1. コンプライアンスの適合率と非適合端末の数
2. 重大度が高い未適用パッチを持つ端末の数
3. 30日以上Automoxに応答していない端末の数
数字は取得したものだけを使い、取れない項目は
「取得できず」と書いてください。変更操作はしないでください。出力は、上の3項目を並べた下書きになります。ツールの返す値が元なので、報告に載せる前に数字をコンソールで1度見比べます。READMEにも「AIは間違えることがあり、重要な結果は行動の前にコンソールで確かめる」という注意書きがあります。
月次で繰り返すなら、前月の数字を貼って差分を出させる使い方が向いています。Automoxの履歴をClaudeに遡らせるより、毎月の報告の数字を自分で残しておくほうが再現性があります。
定型の調査手順はワークフロープロンプトに任せる
サーバーは6つのワークフロープロンプトを持ちます。端末の調査、ポリシーの監査、グループの導入、Patch Tuesdayの準備、セキュリティ状況の確認、失敗の切り分けです。ディレクトリのページでは名前が audit_policy・investigate_device・onboard_group・patch_tuesday・security_posture・triage_failure と並びます。
違反端末の原因を追うときは、investigate_device 系の手順が役立ちます。ツールリファレンスでは、非適合の端末について端末の詳細、インベントリ、パッケージ、ポリシーの状況、実行履歴を順にたどり、原因を探る流れと説明されています。ゼロから質問を組み立てるより、抜けが出にくい構成です。
読み取り専用で使うなら、Patch Tuesdayの準備と状況確認の2つが中心になります。承認や修復の適用まで進む手順は、書き込み権限があって初めて意味を持ちます。
ホスト型サーバーには、ローカル版にない機能が1つあります。Automoxが用意するポリシーのテンプレート集を検索し、そこからポリシーを作る機能です。README上は「ホスト型のみ」で、Claude Desktopから使える形ではありません。
管理者が事前に知っておくこと
組織への影響として、次の点があります。
- ツールはAutomox社が提供するもので、ディレクトリのページにも「信頼できる開発元のコネクタだけを使う」旨の注意があります。Anthropicはツールの内容を管理しないと書かれています。
- READMEによると、サーバーはAutomox APIとだけ通信し、テレメトリを送りません。取得したデータはそのまま会話に返ります。ただし会話に返った端末名やIPなどの資産情報が、Claude側でどう扱われるかはREADMEに書かれていません。利用中のプランの規約で確かめてください。
- API応答はプロンプトインジェクション対策のためサニタイズされます(
AUTOMOX_MCP_SANITIZE_RESPONSES、既定は有効)。端末名やポリシー名に命令文が仕込まれる経路への備えです。 - ローカル版の呼び出しは、READMEの記載で60秒あたり30回までのレート制限があります。全端末の明細を何度も取り直す使い方には向きません。
Claude Enterpriseでコネクタ自体を制限したい場合は、コネクタの制限設定を先に確認してください。コネクタ全般の仕組みはClaude Connectorsの解説にまとまっています。