vmware-monitor

VMware Monitor（読み取り専用）

免責事項：これはコミュニティが保守するオープンソースプロジェクトであり、VMware, Inc. または Broadcom Inc. とは提携、推奨、後援のいずれも受けていません。「VMware」と「vSphere」は Broadcom の商標です。ソースコードは、MIT ライセンスの下で github.com/vmware-skills/VMware-Monitor にて公開監査できます。

読み取り専用の VMware vCenter／ESXi 監視 — 33 個の MCP ツール、破壊的なコードはありません。

vSphere に対して読み取り専用：vCenter／ESXi の状態を変更するコードパスはありません。電源操作、作成、削除、スナップショット、再構成の呼び出しは存在しません。vCenter では、ログインセッションと、解放される短時間のクエリハンドルのみを開きます。ゲート： tests/eval/regression/test_read_only_enforcement.py（このバンドルではなくソースリポジトリ内）は、呼び出されるすべての vSphere メソッドがレビュー済み許可リストに含まれ、pyVmomi の型メタデータと照合されることを必須とします。これはソースを検査するもので、実行時の検査ではなく、CI でも実行されません。このコードとは独立して、vCenter の読み取り専用ロールを持つ専用アカウントを使用してください。 ローカルへの書き込み（このマシンのみ）：init は ~/.vmware-monitor/config.yaml と .env に書き込みます（0600。平文のパスワードは読み込み時に b64: として書き換えられます）。監査ログは ~/.vmware/audit.db（MCP と CLI）および ~/.vmware-monitor/audit.log（CLI）に記録されます。--html は ~/vmware-health/ にスナップショットを保存します。daemon start の実行後に限り、scan.log、daemon.pid、およびオプトインした Webhook の投稿が行われます。 関連スキル：vmware-aiops（VM のライフサイクル）、vmware-storage（iSCSI／vSAN）、vmware-vks（Tanzu Kubernetes）、vmware-nsx（NSX ネットワーク）、vmware-nsx-security（DFW／ファイアウォール）、vmware-aria（メトリクス／アラート／キャパシティ）、vmware-avi（AVI／ALB／AKO）、vmware-harden（コンプライアンスのベースライン）。 | vmware-pilot（ワークフローのオーケストレーション） | vmware-policy（監査／ポリシー）

このスキルでできること

カテゴリ	機能
クラスタートリアージ	一目でわかる get_cluster_health_summary — クラスター横断の問題／キャパシティ／ヘルスの集計と、明確なステータスを表示。ビューのカスタマイズも可能
オブジェクト調査	「この VM／ホスト／データストアの周辺で何が起きているか？」— オブジェクトごとに関連情報をまとめてドリルダウン表示し、get_cross_vcenter_attention では、設定済みのすべての vCenter を横断して「今、対応が必要なもの」を優先度順に一覧表示
インベントリ	VM、ESXi ホスト、データストア、クラスター、ネットワークの一覧表示
ヘルス	アクティブなアラーム、最近のイベント（重大度／時間で絞り込み）、ハードウェアセンサー、ホストサービス
パフォーマンス	ホストと VM の CPU／メモリ／ディスク／ネットワーク使用率をリアルタイムで表示（PerfManager）
キャパシティ	データストアのシンプロビジョニングのオーバーコミット、リソースプールの予約／使用状況
インフラのヘルス	ESXi 証明書の有効期限、ライセンスの使用状況／有効期限、NTP 設定のヘルス
スナップショット	インベントリ全体のスナップショット経過時間と増加状況（古いスナップショットを検出）
アクティビティ	実行中のタスク、アクティブなログインセッション
VM の詳細	CPU、メモリ、ディスク、NIC、スナップショット、ゲスト OS、IP
スキャン	Slack／Discord Webhook を使用した、スケジュール設定可能なアラーム／ログのスキャン
vSphere 9.1	ホストのメモリ階層化（DRAM／NVMe の性能向上）、vLCM クラスターのパッチ適用コンプライアンスと最終適用結果、vCenter のデプロイサイズ

クイックインストール

uv tool install vmware-monitor==2.4.2
vmware-monitor doctor

このスキルを使う場面

• VM、ホスト、データストア、クラスターを一覧表示または検索する
• アクティブなアラームや最近のイベントを確認する
• 特定の VM の詳細情報を取得する
• Webhook アラートを使ったスケジュール監視を設定する
• 安全性が最重要となる、読み取り専用の VMware クエリ全般

アラーム／イベントの出力：suggested_actions フィールド

get_alarms と get_events の結果には、エージェントがそのまま実行できる、すぐに使える関連スキルのツール呼び出し（例："vmware-aiops: acknowledge_vcenter_alarm(...)"）が suggested_actions として含まれます。例については references/capabilities.md を参照してください。

関連スキルを使用するケース：

• 電源オン／オフ、デプロイ、クローン、移行 --> vmware-aiops
• iSCSI、vSAN、データストアの管理 --> vmware-storage
• Tanzu Kubernetes クラスター --> vmware-vks
• 負荷分散、AVI／ALB、AKO、Ingress --> vmware-avi

関連スキル — スキルの振り分け

ユーザーの意図	推奨スキル
読み取り専用の vSphere 監視	vmware-monitor ← このスキル
ストレージ：iSCSI、vSAN、データストア	vmware-storage
VM のライフサイクル、デプロイ、ゲスト操作	vmware-aiops
Tanzu Kubernetes（vSphere 8.x 以降）	vmware-vks
NSX ネットワーク：セグメント、ゲートウェイ、NAT	vmware-nsx
NSX セキュリティ：DFW ルール、セキュリティグループ	vmware-nsx-security
Aria Ops：メトリクス、アラート、キャパシティプランニング	vmware-aria
承認を伴う複数ステップのワークフロー	vmware-pilot
コンプライアンスベースライン（CIS／等保／PCI-DSS）、ドリフト検出、LLM 修復アドバイザー	vmware-harden（uv tool install vmware-harden）
ロードバランサー、AVI、ALB、AKO、Ingress	vmware-avi（uv tool install vmware-avi）
監査ログのクエリ	vmware-policy（vmware-audit CLI）

一般的なワークフロー

診断調査：「X が失敗／停止／異常なのはなぜか」というワークフローを実行する前に、references/investigation-protocol.md に従ってください。根本原因を特定するための 4 つの完全性基準（反証可能性／十分性／必要性／メカニズム）と、最大 3 ラウンドの深掘りループが適用されます。vmware-monitor は読み取り専用のため、データソースとして機能します。操作は vmware-aiops などの関連スキルで行います。

クラスターのヘルスチェック（「何か問題が起きていますか？」／「今、何が起きていますか？」）

判断：これは 5 秒で状況を見極めるためのもので、Aria の代替ではありません。1 回の呼び出しで、すべてのクラスターのホスト、VM の電源状態、リアルタイムの CPU／メモリ、アラームを集約し、個々の異常を順位付けした 上位 N 件の注目リスト（top_issues）にまとめ、各クラスターに明確な status を割り当てます。大規模な環境では、クラスターごとの行を確認するには時間がかかりすぎるため、まず注目リストを確認してください。

1. まず全体を確認 --> vmware-monitor summary（MCP：get_cluster_health_summary）。最初に top_issues を確認します（重大度の高い順で、それぞれに詳細調査の next step が付いています）。クラスターごとの表は状況を把握するためのものです。issues_total には、上位 N 件への絞り込み前に存在した異常の数が表示されます
2. 注目範囲を狭める／広げる --> 最も緊急度の高い 5 件には --top 5、件数を増やすには --top 20、リストを非表示にして表だけを表示するには --top 0 を指定します
3. リストが示す項目を詳しく調べる --> 例：host_down の行なら inventory hosts、alarm の行なら get_alarms、capacity の行なら perf hosts／capacity datastores を実行します。対象を絞り込むには --cluster prod-a を指定します
4. 要望に応じて表示を組み替える --> 出力の最後に操作しやすいヒントが表示されます。オペレーターは「データストアの空き容量を追加」「要対応のクラスターだけ表示」「これを HTML ページとして保存」などと依頼できます。既定のレイアウト、列、しきい値は references/health-summary-template.md に記載されており、編集を想定しています
5. オフラインスナップショットを保存 --> vmware-monitor summary --html を実行すると、自己完結型の HTML ファイル（外部アセットなし、アップロードなし）が ~/vmware-health/cluster-health-<vc>-<timestamp>.html に書き込まれます。保存先を明示するには --html-path <file> を指定します。これはスナップショットであり、ライブページではありません。更新するには再実行してください
6. 非常に大規模な環境の場合 --> ホスト／アラーム／キャパシティのシグナルだけが必要なときは、VM 集約の処理を省略するために --no-vms を追加します
7. totals.clusters が 0 の場合 --> 空という意味ではありません。クラスターに属さないホスト（スタンドアロン ESXi、またはクラスターのない vCenter）は (standalone hosts) の行にまとめられ、totals と top_issues にも含まれます

日次のヘルスチェック

判断：アラームは vCenter が何を問題と判断したかを示し、イベントは何が起きたかを示します。両者は異なる場合があります。アラームがないのにイベントが急増している場合、「すべて問題ない」ということではなく、メトリクスのしきい値が適切に調整されていないことを示している場合がよくあります。両方を確認してください。

1. アラームを確認します --> vmware-monitor health alarms --target prod-vcenter — 重大度が Red のアラームと、発生から 1 時間以上経過したアラームに注目します
2. 最近のイベントを確認します --> vmware-monitor health events --hours 24 --severity warning — 同じエンティティでイベントが繰り返されていないか確認します（イベントが 1 件ならノイズですが、1 時間に 50 件ならパターンです）
3. ホストを一覧表示します --> vmware-monitor inventory hosts — 切断中のホスト、予期せずメンテナンスモードになっているホスト、またはメモリ使用率が 90% を超えるホストを特定します
4. 接続に失敗した場合 --> vmware-monitor doctor を実行して、設定やネットワークの問題を診断します
5. ツールが NoPermission を返す場合や、結果が少なすぎる場合 --> vmware-monitor access-info --tool <tool>（MCP：get_access_info）で、そのアカウントで実行できる操作を確認できます

オブジェクトを起点とした調査（「この VM／ホスト／データストアの周辺で何が起きているか？」）

判断：トリアージで問題の兆候が見つかった後にオペレーターが求める詳細調査です。1 回の呼び出しでオブジェクトと周辺のインフラストラクチャおよび最近の履歴を関連付けるため、5 つのツールの結果を自分でつなぎ合わせるのではなく、集約結果を運用上の表現で説明できます。ツールが集約を行うため、生のインベントリを会話にそのまま出す必要はありません。

段階的に案内し、環境ですでに決まっている詳細を尋ねないでください。

1. 最初に全体を確認します --> すべての vCenter を対象に「今、対応が必要なのは何か？」を確認するには get_cross_vcenter_attention（CLI：vmware-monitor attention）を使います。設定済みの vCenter が 1 つだけの場合は、どの対象か尋ねる必要はありません。直接、その get_cluster_health_summary に進みます
2. オブジェクトの詳細調査を提案します。トップレベルの問題一覧にある項目を対象にします。どのレベルを調べるかが本当に曖昧な場合に限り、確認してください。
   • VM --> investigate_vm（CLI：vmware-monitor investigate vm <name>）→ VM の状態、最近のイベント、スナップショット、アラームと最近の変更、実行先のホスト、クラスターの状況、それを支えるデータストア、パフォーマンスの兆候、関連付けられたイベントのタイムライン
   • ホスト --> investigate_host（CLI：investigate host <name>）→ ホストの状態、クラスターの状況、実行中の VM、マウントされたデータストア、アラーム、パフォーマンス、関連付けられたタイムライン
   • データストア --> investigate_datastore（CLI：investigate datastore <name>）→ 容量／空き容量、マウントしているホスト、支えている VM、アラーム、関連付けられたタイムライン
3. 要望に応じて範囲を広げたり絞ったりします --> より長いイベント期間には --hours 72 を指定します。バンドルの末尾に、調整可能な項目のヒントが表示されます
4. 具体的な形にします --> 任意の investigate／attention コマンドに --html を追加すると、オフラインで使える自己完結型のスナップショットが ~/vmware-health/ に作成されます（詳細調査のセクションは標準機能で折りたたみ／展開でき、JS は不要で、何もアップロードされません）
5. オブジェクト名が不明な場合 --> ツールは、オブジェクトの一覧表示方法（list_virtual_machines／list_esxi_hosts／list_all_datastores）を明示した、案内付きのエラーを返します。正確な名前を取得して再試行してください
6. vCenter に到達できない場合（attention のみ）--> 理由とともに unreachable の下に表示され、残りは引き続き集約されます。全体の表示を失敗させず、欠落があることを伝えてください

パフォーマンスのトリアージ（「クラスターの動作が遅い」）

判断：インベントリから分かるのは 設定上の 容量（コア数、GB）であり、実際に負荷が高いものは分かりません。リアルタイムのパフォーマンスツールを使ってから、対象を絞り込みます。

1. ホストを順位付けします --> vmware-monitor perf hosts — 最もビジーなホストが先頭に表示されます（CPU%順）
2. 問題のホスト上のVMを順位付けします --> vmware-monitor perf vms --limit 25 — 負荷の高い隣接VMを見つけます
3. 表面化していないストレージの逼迫を確認します --> vmware-monitor capacity datastores — オーバーコミット率が100%を超えている場合、「空き」容量が表示されていても、シンプロビジョニングされたデータストアが実行中に満杯になる可能性があります
4. スナップショットによる遅延を除外します --> vmware-monitor snapshots aging --only-old — 古いスナップショットは気付かないうちにI/O性能を低下させます
5. パフォーマンスツールの結果が空の場合 --> ホストまたはVMが切断されているか、電源がオフの可能性があります（リアルタイムプロバイダーがありません）。inventory hosts / inventory vms で確認してください

計画停止前の確認（証明書、ライセンス、時刻）

1. 証明書の有効期限 --> vmware-monitor infra certs --warn-days 60 — ESXi証明書が期限切れになると、ホスト管理ができなくなります
2. ライセンスの余裕 --> vmware-monitor infra licenses — 機能が無効になる前に、割り当て超過を検出します
3. 時刻同期 --> vmware-monitor infra ntp — healthy: no の場合、SSO/Kerberos/ログの相関に問題が生じます（注：SOAP APIでは現在のオフセットは公開されず、設定の健全性のみ確認できます）

継続的な監視を設定する

1. ~/.vmware-monitor/config.yaml でWebhookを設定します
2. デーモンを起動します --> vmware-monitor daemon start
3. デーモンは15分ごとにスキャンし、Slack/Discordにアラートを送信します

使用モード

シナリオ	推奨	理由
ローカル／小規模モデル（Ollama、Qwen）	CLI	約2Kトークン。MCPでは約8Kトークン
クラウドモデル（Claude、GPT-4o）	どちらでも	MCPでは構造化JSON I/Oを利用できます
自動化パイプライン	MCP	型安全なパラメーターと構造化出力

MCP ツール（33 — すべて読み取り専用）

ツール	説明
list_virtual_machines	フィルター（電源状態、並べ替え、上限、folder_filter）を指定して VM を一覧表示します。各 VM には folder_path が含まれます
list_esxi_hosts	CPU、メモリ、バージョン、稼働時間を含む ESXi ホスト
list_all_datastores	容量、空き領域、タイプを含むデータストア
list_all_clusters	ホスト数、DRS／HA の状態を含むクラスター
get_cluster_health_summary	すべてのクラスターを一目でトリアージします。優先順位付きの top_issues 注目リストと、判断に基づく status を含むクラスターごとの概要を表示します。パラメーター：cluster_filter、include_vms、top_n。references/health-summary-template.md に従って表示します
investigate_vm	「この VM の周辺で何が起きていますか？」— 相関する詳細調査と、統合された新しい順のイベントタイムラインを表示します（内容は上記のワークフローに記載）。パラメーター：vm_name、hours。ツールで集約されるため、生データをそのまま出すのではなく説明してください
investigate_host	ESXi ホストを中心に、同様の相関する詳細調査を行います。パラメーター：host_name、hours
investigate_datastore	データストアを中心に、同様の相関する詳細調査を行います。パラメーター：datastore_name、hours
get_cross_vcenter_attention	設定済みのすべての vCenter を対象に、「今、何に注意が必要ですか？」を確認します。グローバルに順位付けされた top_issues リスト（各項目に vcenter を付記）と対象ごとの概要を表示します。到達不能な対象があっても、適切に処理を続行します。パラメーター：cluster_filter、top_n
list_all_networks	接続された VM 数とアクセス可能性を含むネットワーク
get_alarms	アクティブなアラーム：suggested_actions、確認者、condition_now（cleared は古いアラームを示します）
get_events	重要度と時間範囲（start／end）でイベントを取得します
get_host_sensors	ホストごとのハードウェアセンサー状態（温度／電圧／ファン）と、緑／黄／赤の健全性
get_host_services	ホストサービスの状態（稼働状態と起動ポリシー）。必要に応じてホストで絞り込めます
get_vm_info	VM の詳細情報（CPU、メモリ、ディスク、NIC、スナップショット）
list_vm_snapshots	1 台の VM のスナップショット一覧とネスト階層（読み取り専用）
get_host_performance	リアルタイムのホスト CPU／メモリ／ディスク／ネットワーク使用率（PerfManager）。使用率の高い順
get_vm_performance	リアルタイムの VM CPU／メモリ／バルーン／スワップ／ディスク／ネットワーク使用率（デフォルトでは上位 25 件）。電源オンの VM のみ
find_aging_snapshots	インベントリ全体のスナップショットを調査し、経過日数と増加状況を確認します。N 日を超えるスナップショットにフラグを付けます
get_vm_backup_snapshot_history	スナップショットタスク履歴から、1 台の VM のバックアップウィンドウを取得します。下限を示すものであり、ジョブの実行時間ではありません
get_certificate_status	ESXi 管理証明書の有効期限をホストごとに表示します（有効期限までの日数、期限切れ間近のフラグ）
get_license_status	ライセンスとアセットごとの assignments
get_ntp_status	ホストごとの NTP 設定の健全性（サーバーと ntpd の状態）。ライブオフセットは SOAP API では取得できません
get_datastore_capacity	データストアの過剰コミット（プロビジョニング済み容量と実容量の比較）。シンプロビジョニングのリスクを確認します
get_resource_pool_usage	リソースプールの CPU／メモリの予約、上限、現在の使用量
list_active_tasks	実行中および最近完了した vCenter タスクと、進捗／エラー
list_active_sessions	ログイン中のユーザーと、その接続元クライアント
get_access_info	使用中のアカウントと、そのアカウントがルートフォルダーでツールの権限を持つかどうか（undetermined は権限が付与されていないことを示します）
scan_host_logs	ESXi ホストログの問題行をパターンごとに分類します（CLI：scan logs）
get_host_memory_tiering	vSphere 9.1 — ホストごとのメモリ階層（DRAM／NVMe 階層）と NVMe 向上率（pyVmomi の hardware.memoryTierInfo、ESXi 8.0U3 以降が必要）。パラメーター：host_name、limit。リスト形式のエンベロープを返します
get_cluster_patch_compliance	vSphere 9.1 — vSphere Automation REST を介して、1 つのクラスターの vLCM ソフトウェア（パッチ）準拠状況を確認します。パラメーター：cluster（MoID。例：domain-c123）。available:false は vCenter が 503 を返したこと（パッチ適用中の可能性が高い）を示し、エラーではありません。ホストの状態フィールドが不明な場合、non_compliant_hosts は null となり、誤って 0 になることはありません
get_cluster_last_apply_result	vSphere 9.1 — 1 つのクラスターで最後に実行された vLCM 修復（適用）の結果（REST）。パラメーター：cluster（MoID）。結果のみを報告し、修復は実行しません
get_vcenter_deployment_size	vSphere 9.1 — vCenter アプライアンスのデプロイサイズクラス（REST、9.1 で新規）。503 の場合は available:false

vSphere 9.1 のフィールド解析に関する正直な説明：3 つの REST ツールの エンドポイント は仕様に照らして検証済みですが、JSON フィールド名はまだ稼働中の 9.1 vCenter に対して再検証されていません。各フィールドは防御的に読み取られ、結果には note を使って endpoint verified; field parse best-effort pending live 9.1 vCenter と明記されます。get_host_memory_tiering には vCenter／ESXi 8.0U3 以降が必要です。古いターゲットでは、不足しているプロパティ名を示す説明エラーが発生します。

vCenter／ESXi リソースを変更、作成、削除するツールはありません。 パフォーマンス／容量の測定値はその時点でのサンプルです。このスキルは 履歴を保持しないため、架空の「傾向」や枯渇予測日を報告することはありません。

リスト結果の形式

上記の 21 個の行リストツール（get_host_memory_tiering を含む）は、生の配列ではなく、共通のリストエンベロープ {items, returned, limit, total, truncated, hint} を返します。要約する前に truncated を確認してください。true は行がまだあることを意味します。items だけを全体とみなさないでください。false はすべて取得済みであることを意味するため、items が空なら「確認した結果、該当なし」です。ただし、scan_host_logs では、読み取れなかったログである logs_unavailable も空の場合に限ります。total が null（get_events、scan_host_logs）なのは意図的です。集計ツールは 用途に応じたオブジェクトを返します。references/capabilities.md を参照してください。

読み取り専用として設計

33 個のツールはすべて vSphere の読み取り専用です（ローカルへの書き込みについては冒頭を参照）。ローカルモデルや小規模なモデルで実行する場合は、 references/agent-guardrails.md を参照してください。

CLI クイックリファレンス

vmware-monitor summary [--top 10] [--cluster <substr>] [--html] [--target <t>]
vmware-monitor inventory vms|hosts|datastores|clusters|networks [--target <t>]
vmware-monitor health alarms|events|sensors|services [--target <t>]
vmware-monitor perf hosts|vms [--target <t>]
vmware-monitor capacity datastores|pools [--target <t>]
vmware-monitor infra certs|licenses|ntp [--target <t>]
vmware-monitor snapshots aging [--only-old] [--target <t>]
vmware-monitor vm info <vm-name> [--target <t>]
vmware-monitor memory tiering [--host <esxi>] [--target <t>]        # vSphere 9.1
vmware-monitor patch compliance|last-apply <cluster-moid> [--target <t>]   # vSphere 9.1 (vLCM)
vmware-monitor deployment-size [--target <t>]                      # vSphere 9.1
vmware-monitor scan now | scan logs [--host <name>] | daemon start|stop|status | doctor [--skip-auth]

すべてのフラグとアクティビティ／タスク／セッションを含む CLI リファレンスについては、references/cli-reference.md を参照してください。

トラブルシューティング

Alarms が空を返すのに、vCenter にはアラームが表示される

get_alarms ツールは、ルートフォルダー階層のトリガー済みアラームを照会します。一部のアラームはエンティティ固有です。その場合は、代わりにイベントを確認してください：get_events --hours 1 --severity info。

「Connection refused」エラー

1. vmware-monitor doctor を実行して診断します
2. config.yaml のターゲットホスト名／IP アドレスとポート（443）を確認します
3. 検証対象がラボの自己署名証明書の場合のみ：verify_ssl: false

Events の結果が多すぎる

重大度フィルターを使用します：--severity warning（デフォルト）では情報レベルのイベントが除外されます。--hours 4 を使用して時間範囲を絞り込みます。

VM 情報に「guest_os: unknown」と表示される

VMware Tools がゲスト OS にインストールされていないか、実行されていません。ゲスト OS の検出、IP アドレス、ゲストファミリー情報を取得するには、VMware Tools をインストールして起動してください。

Doctor は成功するのに、コマンドがタイムアウトする

vCenter に高い負荷がかかっている可能性があります。vCenter ではなく、特定の ESXi ホストを直接ターゲットにするか、config.yaml で接続タイムアウトを延長してください。

すべてのコマンドが「session is not authenticated」で失敗する

アカウントに vSphere ロールがありません。vCenter のルートフォルダーにロール（読み取り専用以上）を割り当ててください。vmware-monitor doctor はこのケースを名前で報告します。

読み取り専用スキルに environment: を設定する必要はありますか？

任意です。~/.vmware-monitor/config.yaml の各ターゲットに environment: production（または staging、lab、独自のラベル）を追加できます。読み取り操作がこの設定によって制限されることはありません。 同じ vCenter 上の書き込みスキル（vmware-aiops、vmware-storage、 vmware-nsx）には関係します。環境を指定した deny ルールを ~/.vmware/rules.yaml に設定すると、そのラベルに一致する書き込みをブロックできます（例：production の凍結）。 設定例は references/setup-guide.md を参照してください。

セットアップ

uv tool install vmware-monitor==2.4.2
vmware-monitor init      # guided: prompts for host/user/password, writes config + .env (chmod 600), then verifies

init はパスワードを grep で検出されない形式（平文ではなく、難読化された b64:）で保存し、 .env のパーミッションを 0600 に設定します。手動で編集するより init の使用をおすすめします。手動での手順は references/setup-guide.md を参照してください。

セットアップの完全なガイド、セキュリティの詳細、AI プラットフォームとの互換性については、references/setup-guide.md を参照してください。

監査と安全性

MCP 呼び出し（@vmware_tool）とリモート CLI コマンド（@audited）は vmware-policy によって監査されます。CLI クエリは ~/.vmware-monitor/audit.log にも追記されます。

• すべての MCP 呼び出しとリモート CLI コマンドは ~/.vmware/audit.db（SQLite）に記録されます
• ~/.vmware/rules.yaml によってポリシールールが適用されます（拒否ルール、メンテナンス時間帯、リスクレベル）
• リスク分類：各ツールには低／中／高／重大のいずれかが割り当てられます
• 最近の操作を表示：vmware-audit log --last 20
• 拒否された操作を表示：vmware-audit log --status denied

ライセンス

MIT — github.com/vmware-skills/VMware-Monitor