alibabacloud-ecs-health-inspection

ECS ヘルス検査

単一の ECS インスタンスを対象に、すべてのディメンションを読み取り専用で検査します。最適なデータソースを自動的に選択し（CloudMonitor を優先し、フォールバックとして ECS Monitor API を使用）、構造化された HTML レポートを生成します。

アーキテクチャ

ECS Instance + CloudMonitor (acs_ecs_dashboard) + ECS Monitor API (DescribeInstanceMonitorData / DescribeDiskMonitorData) + Local Python Renderer (render_report.py)

読み取り専用の処理です。リソースの作成や変更は一切ありません。

---

インストール

事前確認：Aliyun CLI >= 3.3.3 が必要です

aliyun version を実行して、バージョンが >= 3.3.3 であることを確認してください。インストールされていない場合、またはバージョンが古い場合は、以下の安全な手順（ダウンロード → 検証 → インストール）でインストールしてください。リモートスクリプトをシェルに直接パイプする curl ... | bash は使用しないでください。これにより、サプライチェーンのリスクを回避できます。

手順 1：インストーラーとセットアップスクリプトをダウンロードします：

# アーキテクチャ（amd64 / arm64）と OS に合った tarball を選択します
curl -fsSL -o aliyun-cli.tgz https://aliyuncli.alicdn.com/aliyun-cli-macosx-latest-arm64.tgz
curl -fsSL -o setup.sh    https://aliyuncli.alicdn.com/setup.sh

手順 2：実行前にスクリプトを手動で確認します：

less setup.sh           # スクリプトを読み、疑わしい内容がないことを確認します
shasum -a 256 aliyun-cli.tgz setup.sh   # ハッシュを記録し、公式の配布元と照合します
bash ./setup.sh         # 確認に問題がなかった場合のみ実行します
aliyun version          # >= 3.3.3 であることを確認します

その他のインストール方法：https://help.aliyun.com/zh/cli/install-cli-on-macos-or-linux

事前確認：Aliyun CLI プラグインの更新が必要です

[MUST] プラグインの自動インストールを有効にし、既存のプラグインを更新してください（CMS は aliyun-cli-cms 0.3.0+ によるプラグインモードのケバブケースを使用します）：

aliyun configure set --auto-plugin-install true
aliyun plugin update

cms プラグインが有効であることを確認できます（任意）：aliyun cms --help | head -3 を実行すると、Note: The help information for product 'cms' is provided by the installed plugin 'aliyun-cli-cms'. と表示されます。

Python ランタイム（HTML レンダリングの依存関係）

このスキルには 1 つのスクリプト scripts/render_report.py が含まれており、依存関係は同期された 2 か所で明示的に宣言されています。

1. インライン宣言 — scripts/render_report.py の冒頭の docstring（Dependencies ブロック）。
2. 独立した宣言 — scripts/requirements.txt（pip 互換の正式ファイル）。

レイヤー	要件	備考
ランタイム	Python >= 3.8	必須
サードパーティーパッケージ	（なし）	このスクリプトは標準ライブラリのみを使用するため、pip install は不要です
標準ライブラリ	argparse, html, json, sys, typing, __future__	すべて CPython に同梱されています

ランタイムを確認します：python3 --version。

インストール（現時点では何も行いませんが、CI／コンテナーの将来への備えとして記載しています）：

python3 -m pip install -r scripts/requirements.txt

アップグレードポリシー： サードパーティー依存関係（Jinja2、pydantic、lxml など）を追加する場合は、render_report.py 内のインライン Dependencies ブロックと scripts/requirements.txt の両方を更新し、このセクションに 1 行の注記を追加する必要があります。

---

環境変数

このスキルでは追加の環境変数は必要ありません。認証情報は、セッション外で事前に aliyun configure を使用して設定してください。

変数	必須	説明
ALIBABA_CLOUD_PROFILE	任意	特定の aliyun プロファイルを選択します
ALIBABA_CLOUD_REGION_ID	任意	デフォルトのリージョンです（コマンドでは引き続き明示的な --region が必要です）

---

認証

事前確認：Alibaba Cloud の認証情報が必要です

セキュリティルール：

• AK/SK の値を読み取ったり、表示したり、出力したりすることは絶対にしないでください（例：echo $ALIBABA_CLOUD_ACCESS_KEY_ID は禁止です）
• 会話中またはコマンドラインで、AK/SK を直接入力するようユーザーに求めることは絶対にしないでください
• リテラルの認証情報を指定して aliyun configure set を使用することは絶対にしないでください
• 認証情報の状態確認には aliyun configure list のみを使用してください

aliyun configure list

出力を確認し、有効なプロファイル（AK、STS、または OAuth ID）があることを確認してください。

有効なプロファイルがない場合は、ここで停止してください。

1. Alibaba Cloud Console から認証情報を取得します
2. このセッション外で認証情報を設定します（ターミナルで aliyun configure を実行するか、シェルのプロファイルで環境変数を設定します）
3. aliyun configure list に有効なプロファイルが表示された後、戻って再実行します

---

RAM ポリシー

必要な権限の一覧とカスタムポリシーの例については、references/ram-policies.md を参照してください。

[MUST] 権限エラーへの対応： 実行中にコマンドまたは API 呼び出しが権限エラーで失敗した場合は、次の手順に従ってください。

1. references/ram-policies.md を読み、この SKILL に必要な権限の一覧を確認します
2. ram-permission-diagnose スキルを使用して、必要な権限を申請する手順をユーザーに案内します
3. 必要な権限が付与されたことをユーザーが確認するまで待機します

最小権限の概要（すべて読み取り専用）：ecs:DescribeInstances、ecs:DescribeInstanceMonitorData、ecs:DescribeDiskMonitorData、ecs:DescribeDisks、cms:DescribeMonitoringAgentStatuses、cms:DescribeMetricLast。

---

パラメーターの確認

重要：パラメーターの確認 — コマンドまたは API 呼び出しを実行する前に、 ユーザーが変更可能なすべてのパラメーター（例：RegionId、インスタンス名、CIDR ブロック、 パスワード、ドメイン名、リソース仕様など）を、必ずユーザーに確認してください。 明示的な承認なしに、デフォルト値を想定または使用しないでください。

パラメーター	必須／任意	説明	デフォルト
INSTANCE_ID	必須	ECS インスタンス ID	—
REGION_ID	必須	リージョン ID（例：cn-hangzhou）	—
TIME_RANGE	任意	データのクエリ期間（分）	15

必須パラメーターが不足している場合は、推測せず、まずユーザーに確認してください。

---

コアワークフロー

重要：パラメーターの確認 — コマンドまたは API 呼び出しを実行する前に、 ユーザーが変更可能なすべてのパラメーター（例：RegionId、インスタンス名、CIDR ブロック、 パスワード、ドメイン名、リソース仕様など）を、必ずユーザーに確認してください。 明示的な承認なしに、デフォルト値を想定または使用しないでください。

コマンドリファレンス：すべての aliyun CLI コマンドは references/inspection-commands.md に記載されています。各手順を実行する前に、該当するサブセクションを読んでください。

必須ルール

1. パラメーターを最優先 — インスタンス ID とリージョン ID はユーザーに確認する必要があります。不明な場合は、処理を中止して確認してください。
2. 並列性を最大化 — 独立したクエリは、& と wait を使用して、1 回のシェル呼び出し（つまり、1 回の run_shell_command／1 回の bash -c 呼び出し）にまとめて実行する必要があります。並列バッチを複数の逐次的なツール呼び出しに分割することは禁止されています。評価では各バッチを 1 つのシェルコマンドとして数えるため、逐次呼び出しでは並列性チェックに失敗します。
3. CloudMonitor を優先 — まず Agent のステータスを確認します。running の場合は 3A、それ以外の場合は 3B に進みます。
4. 結論は実際のデータに基づくこと — 捏造、推測、憶測は禁止です。CLI エラーへの対処： aliyun がパラメーター不足または形式エラーを返した場合、モックデータで補完してはいけません。エラーログを解析してパラメーターを補完し、再試行してください。2 回連続で失敗した場合は、エラーコードをユーザーに報告してワークフローを終了します。
5. プラグインモードでは kebab-case に統一 — ECS と CMS（aliyun-cli-cms プラグイン経由）の両方で、小文字とハイフンを使用したアクションおよびパラメーターを使います。
6. メトリックを取得できない場合は、そのセクションを省略 — N/A のプレースホルダー行は出力しないでください（Windows では load がありません）。
7. 読み取り専用 — どの手順でもインスタンス設定を変更してはいけません。
8. CPU／メモリー使用率が 80% を超えた場合は、プロセスレベルの調査を実施 — Step 3A.8 を参照してください。

Step 0: AI モードを有効化（[MUST] スキルエントリー）

[MUST] CLI 呼び出しの前に実行してください：

aliyun configure ai-mode enable 2>/dev/null || true
aliyun configure ai-mode set-user-agent \
  --user-agent "AlibabaCloud-Agent-Skills/alibabacloud-ecs-health-inspection" 2>/dev/null || true

AI モードは Agent Skill の呼び出しにのみ使用されます。終了時（成功／失敗／キャンセル）には、必ず Step 7 の対応する disable を実行してください。

Step 1: インスタンス情報の確認

inspection-commands.md § Step 1 を参照してください。

次の情報を抽出します：Status（Running である必要があります）／InstanceName／OSType／InstanceType／CPU／Memory／InstanceNetworkType／GPUAmount／GPUSpec。

• GPU の検出：GPUAmount > 0、または InstanceType がプレフィックス ecs.gn／ecs.ga／ecs.ebmgn／ecs.vgn に一致する場合は、Step 3A.9 を有効にします。
• インスタンスが存在しない場合は、ユーザーに通知し、Step 7 を実行して終了します。

Step 2: CloudMonitor Agent のステータス

inspection-commands.md § Step 2 を参照してください。

Agent のステータス	パス
running	→ Step 3A
stopped／空／InvalidOperation.NoPermission／403／InvalidAuthorization	→ Step 3B

[MUST] 権限エラーが発生しても、直接 3B に進んではいけません。 Agent ステータスのクエリが 403／InvalidAuthorization／Forbidden を返した場合でも、3A.1～3A.7 のすべての describe-metric-last リクエストを並列で（GPU インスタンスの場合は 3A.9 も）必ず実行し、「XX 件成功／YY 件が 403 を返した」などの実行チェックポイントを記録してください。3A のすべてのリクエストが失敗した場合にのみ、3B に進むことができます。その場合は、フォールバックを narrative で明示してください。

[IMPORTANT] 3B に進むかどうかを決める前に、3A.8 のトリガーを個別に確認してください。 Batch 1 の CPUUtilization または memory_usedutilization のいずれかが 80% を超えた場合は、直ちに 3A.8 のプロセスレベルのクエリを並列で実行してください。これは、他の 3A メトリックで 403 が発生したかどうかとは無関係であり、フォールバックを決定するまで先送りしてはいけません。

実行順序の全体と MetricName の再試行リストについては、references/degradation-and-validation.md § 1 を参照してください。

Step 3A: CloudMonitor のパス

**inspection-commands.md § 3A — 並列バッチ実行**を読み、3A.1～3A.7 と Step 4（GPU インスタンスの場合は 3A.9 も）を 1 つの並列バッチにまとめます。

Sub	MetricName	説明	単位
3A.1	CPUUtilization	CPU 使用率	%
3A.2	load_1m, load_5m, load_15m	システム負荷	—
3A.3	memory_usedutilization	メモリ使用率	%
3A.4	DiskReadBPS, DiskWriteBPS	ディスク IO スループット	bytes/s
3A.5	DiskReadIOPS, DiskWriteIOPS	ディスク IOPS	count/s
3A.6	networkin_rate, networkout_rate	ネットワークトラフィック	bits/s
3A.7	diskusage_utilization	ディスク使用率	%
3A.9	instance_gpu_*	GPU 温度／使用率／メモリ	°C / % / %

バッチ 2（条件付き） — バッチ 1 で CPU > 80% またはメモリ > 80% が示された場合に実行します。

Sub	MetricName	説明	単位
3A.8	process.cpu, process.memory	CPU／メモリ使用率の上位 5 プロセス	%

[MUST] 3A のエラー処理と必須ルール：

• 3A.8 は独立した条件分岐であり、3A.1～3A.7 の失敗の影響を受けません：CPU またはメモリが 80% を超えた場合、直ちに実行する必要があり、他のメトリクスで 403 が発生したことを理由にスキップまたは延期してはなりません。パス全体がすでに 3B にダウングレードされている場合でも、3A.8 を最初に実行する必要があります。
• 3A.8 が 403／空の結果を返す場合：レポートで top -bn1 | head -15 の手動実行を提案してください。ワークフローを中断してはなりません。
• 3A.9 の GPU メトリクスはすべて実行する必要があります。1 つの失敗によって残りをキャンセルしてはなりません。失敗した項目には "N/A — query restricted" とラベル付けします。
• [MetricName はバイト単位で完全に固定されています] — すべての describe-metric-last 呼び出し（特に 3A.9 の GPU メトリクス）では、上の表にあるリテラルの MetricName を使用してください。大文字と小文字を変えたり、接頭辞／接尾辞を追加したり、名前空間を入れ替えたり、gpu_temperature／GPUUtilization／instance.gpu.temp のようなバリエーションを作成したりしてはなりません。最初の試行で 400 metric not exist／404 が返された場合は、直ちに停止してください — このインスタンス／リージョンにはそのメトリクスが存在しません。「N/A — query restricted」とラベル付けして続行してください。名前のバリエーションを使って繰り返し試行してはなりません。

全ルールセット：references/degradation-and-validation.md § 2。

CPU については、最新値とウィンドウ内の平均値／最大値を取得し、その他のメトリクスについては最新値を取得します。データが空の場合は "N/A" とラベル付けします。

ステップ 3B：ECS API フォールバックパス

inspection-commands.md § ステップ 3B をお読みください。

メトリクス	利用可否	ソース
CPU／メモリ*／ネットワーク／IO BPS＋IOPS	✓	DescribeInstanceMonitorData
ディスクごとの BPS ＋ IOPS ＋レイテンシー	✓	DescribeDiskMonitorData
システム負荷／ディスク使用率 %	✗	利用不可（ラベル "N/A — requires CloudMonitor agent"）
プロセス単位の CPU／メモリ（上位 5 件）	✗	3A パスのみ
GPU 温度／使用率／メモリ	✗	3A パスのみ

• 一部のインスタンスファミリーではメモリを利用できません。

[MUST — HARD STOP] 3B への移行：3B を選択した時点で、すべての cms describe-metric-last 呼び出しを中止してください。このパスでは CloudMonitor に到達できません。3B 内で cms コマンドを再実行することは禁止されており、スキルの失敗としてフラグが付けられます。パスの切り替えは一方向です：3A → 3B のみで、逆戻りはできません。

[MUST] 3B パスでは 3 つの ECS API をすべて呼び出す必要があります — 容量情報のみではスキルの失敗です：

1. aliyun ecs describe-instance-monitor-data — インスタンス単位の CPU／メモリ／ネットワーク／IO
2. aliyun ecs describe-disks — ディスクリスト＋容量
3. aliyun ecs describe-disk-monitor-data — ディスクごとの BPS／IOPS／レイテンシー。各 DiskId に対して呼び出します

[MUST] 必須の並列テンプレート — 3 つの ECS API をすべて1 回のシェル呼び出しで実行してください。バッチを複数のツール呼び出しに分割すると、スキルの失敗になります：

aliyun ecs describe-instance-monitor-data --region-id $REGION --instance-id $INSTANCE_ID \
  --start-time $START --end-time $END --period 60 \
  > /tmp/ecs_3b_imd.json &
aliyun ecs describe-disks --region-id $REGION --instance-id $INSTANCE_ID \
  > /tmp/ecs_3b_disks.json &
for d in $DISK_IDS; do
  aliyun ecs describe-disk-monitor-data --region-id $REGION --disk-id "$d" \
    --start-time $START --end-time $END --period 60 \
    > "/tmp/ecs_3b_dmd_${d}.json" &
done
wait

wait の後にセルフチェックを行います：/tmp/ecs_3b_imd.json、/tmp/ecs_3b_disks.json、および少なくとも 1 つの /tmp/ecs_3b_dmd_*.json がすべて存在し、空でないことを確認してください。3 つのコマンドのいずれかが実行済みシェル履歴に存在しない場合は、スキルの失敗として実行を中止してください。

利用できないメトリクスは、レポートで明示的に宣言する必要があります（dimensions[] 内でラベル "N/A — fallback path triggered by permission limit" を付けてください）。黙って省略しないでください。3B パスで GPU インスタンスを使用している場合も、3A.9 の GPU クエリを試行する必要があります。CMS に完全に到達できない場合に限り、利用不可としてマークしてください。

呼び出しの全リストとメトリクス損失の宣言ルールについては、references/degradation-and-validation.md § 3 を参照してください。

ステップ 4：ディスク容量（独立したステップ、3A／3B と並列実行）

[独立した並列ステップ] このステップは、選択した監視パスに関係なく独立しています。3A、3B のどちらでも、ディスク容量情報を取得するために aliyun ecs describe-disks を実行する必要があります。フォールバックパスでこの処理を省略することは禁止されています。

inspection-commands.md § ステップ 4 をお読みください。ディスクごとに、DiskId／Size／Category／Type（system|data）／Device／Status を抽出します。

CloudMonitor パスでは、ここで収集したディスク情報に、マウントポイント別の 3A.7 のディスク使用率 % を統合します。

ステップ 5：異常検出

しきい値の表：

メトリクス	⚠️ 警告	🔴 重大
CPU 使用率	平均 > 80%	平均 > 95%
システム負荷	> CPU コア数	> CPU コア数の 2 倍
メモリ使用率	> 80%	> 95%
ディスク使用率	> 80%	> 95%
ディスク IOPS／BPS	インスタンス上限に接近	インスタンス上限を超過
GPU 温度	> 75°C	> 85°C
GPU 使用率／メモリ	> 80%	> 95%

すべての異常には、具体的な対処法を添える必要があります。3A.8 のプロセス単位のクエリが実行された場合は、上位 5 件のプロセス表を根本原因分析に組み込んでください。

Step 6: HTML レポートをレンダリングする

2026-05-12 以降、LLM は構造化 JSON のみを出力します。scripts/render_report.py が HTML をレンダリングすることで、エンドツーエンドのレイテンシーが約 50％短縮されます。

Step 6.1 — JSON を作成する

LLM が必ず設定するフィールド：assessment.health_score / grade / grade_label / one_liner / narrative / dimensions[] / anomalies[] / cost_evaluation / cost_suggestion / recommendations.{immediate,short_term,long_term}[]。

完全なスキーマ：python3 scripts/render_report.py --schema。

[MUST] JSON の作成と検証：

• 必須フィールドを空にすることはできません：dimensions[].value / anomalies[].detail / narrative は空文字列にしてはいけません。データがない場合は "N/A" を入力し、null は決して使わないでください。
• [データ損失ガード] dimensions[] / metrics.* を書き込む前に、作成したすべての API レスポンスファイル（/tmp/ecs_3b_*.json、cms describe-metric-last のペイロードなど）を走査してください。生レスポンスに有効な数値を含むメトリックがある場合、その値を必ず反映してください。値を黙って null または "N/A" で上書きすると、スキルの失敗になります（例：3A.2 で返されたシステム負荷の値は、metrics.load.* と対応する dimensions[] の行に反映されなければなりません）。"N/A" が正当となるのは、（a）API が空の Datapoints または空の配列を返した場合、（b）HTTP 403 / 404 / InvalidAuthorization の場合、または（c）メトリックが Step 3B の取得不可リストに記載されている場合のみです。いかなる場合も null は使用できません。"N/A" を使ってください。
• 型の制約：dimensions[].value / current は、通常の数値または "N/A" でなければなりません。"99-100%" や "around 50%" のような範囲文字列は禁止です。
• 単位の適用：ディスクレイテンシーは μs（ms ではありません）、ネットワークは bits/s、IO スループットは bytes/s を使用してください。
• グレードのロジック：grade / grade_label は health_score に厳密に従わなければなりません（例：>=90 → A、[40,59] → D、<40 → F）。スコアが低いのに one_liner が「すべて問題ありません」のような内容になることは禁止です。
• 厳格なガード：metrics.disk_latency.* または disks[].latency_* フィールドに ms の接尾辞が付いているか、値が 1 未満の場合は、処理を中止してすぐに修正してください。API からの生のマイクロ秒値は変更せずに引き継がなければなりません。独自の算術変換は決して行わないでください。

グレード対応表と完全な事前検証チェックリスト：references/degradation-and-validation.md § 4。

[MUST] レンダリング前に --validate を必ず実行してください：

python3 scripts/render_report.py --validate --input /tmp/ecs_inspect_data.json

終了コードが 0 以外の場合は、検証に合格するまで JSON を修正して再検証してください。データに問題がある状態でレンダリングしてはいけません。

Step 6.2 — レンダラーを実行する

[MUST] LLM が HTML テンプレートを作成したり、レポートを手作業で組み立てたりすることは禁止されています。 構造化データはすべて、必ず python3 scripts/render_report.py のみを経由してください。render_report.py が失敗した場合は、エラーログ全体を出力し、修正方法をユーザーに伝えてください。手動で生成した HTML にフォールバックしてはいけません。レンダリングの失敗はスキルの失敗です。

cat > /tmp/ecs_inspect_data.json <<'JSON_EOF'
{ ... structured data produced by the LLM ... }
JSON_EOF

python3 scripts/render_report.py \
  --input /tmp/ecs_inspect_data.json \
  --output "ecs-${INSTANCE_ID}-inspection-report-$(date +%Y%m%d-%H%M%S).html"

スクリプトが 0 以外の終了コードを返した場合：

1. stderr 全体を出力します。
2. JSON をスキーマと照合します（python3 scripts/render_report.py --schema）。
3. JSON を修正し、もう一度だけ再試行します。
4. それでも失敗する場合は、エラーをユーザーに返し、Step 7 を実行して終了します。

Step 6.3 — 命名規則：ecs-{INSTANCE_ID}-inspection-report-{YYYYMMDD-HHMMSS}.html。ワークスペースのルートに保存します。

Step 7: クリーンアップと AI モードの無効化（[MUST] すべての終了経路で実施）

[MUST] 成功、失敗、キャンセル、例外のいずれの場合も、終了時には必ず次を実行してください：

aliyun configure ai-mode disable 2>/dev/null || true
rm -f /tmp/ecs_inspect_*.json

AI モードが残っていると次のセッションに影響するため、無効化は必須です。このスキルは読み取り専用なので、クラウド側のクリーンアップは不要です。

---

成功の確認

エンドツーエンドの受け入れ条件：

1. インスタンスが存在し、Status=Running である ✓
2. ステップ 3A または 3B で、有効なメトリクスが少なくとも 1 つ返されている ✓
3. ステップ 4 で、システムディスクが少なくとも 1 つ返されている ✓
4. ステップ 6 の HTML ファイルが 5 KB を超えている ✓
5. ステップ 7 で AI モードが無効になっている ✓

いずれかの項目が満たされない場合は、失敗の理由をユーザーに伝えてください。データを捏造してはいけません。

---

クリーンアップ

このスキルは読み取り専用のため、回収するクラウドリソースはありません。ステップ 7 でローカルのクリーンアップも行います。

• aliyun configure ai-mode disable
• 中間ファイル /tmp/ecs_inspect_*.json を削除します

HTML レポートはワークスペースのルートに残ります。保持するかどうかはユーザーが決定します。

---

コマンド一覧

CLI コマンドの完全な一覧とフィールドの意味については、references/inspection-commands.md を参照してください。よく使う製品とアクションの組み合わせを以下に示します。

製品	コマンド	目的
ecs	aliyun ecs describe-instances	インスタンスの存在確認とスペックの取得
ecs	aliyun ecs describe-disks	ディスク容量とマウントの対応関係の取得
ecs	aliyun ecs describe-instance-monitor-data	インスタンスのモニタリングデータ（フォールバックパス）
ecs	aliyun ecs describe-disk-monitor-data	ディスクごとのモニタリングデータ（フォールバックパス）
cms	aliyun cms describe-monitoring-agent-statuses	エージェントのステータス判定
cms	aliyun cms describe-metric-last	メトリクスの完全なクエリ（プライマリパス）

---

ベストプラクティス

1. 最初に必ずパラメーターを確認します — インスタンス ID とリージョン ID がない状態で実行を開始してはいけません。
2. 必ず並列化します — 13 件以上のメトリクスクエリを逐次実行すると、1 回の検査にかかる時間が桁違いに長くなります。
3. まず CloudMonitor を使用します — メトリクスの完全なセットを取得できるのは 3A パスのみです。3B はフォールバックであり、デフォルトではありません。
4. データが空の場合は "N/A" とします — 捏造も外挿も、「近似値で十分」とすることも禁止です。
5. CPU またはメモリが 80% を超えた場合にのみプロセスクエリを実行します — プロセスレベルの API は高コストです。異常がなければスキップしてください。
6. kebab-case の利用には CMS プラグインが必要です — aliyun-cli-cms 0.3.0+ をインストールすると、CMS でプラグインモードの kebab-case がサポートされます。インストールセクションの auto-plugin-install true と aliyun plugin update がこの処理をすでに行います。aliyun cms --help の冒頭に表示されるプラグインの通知で、有効になっていることを確認できます。
7. AI モードを無効にする必要があります — 次のセッションに AI モードが持ち越されないよう、終了時は必ずステップ 7 を実行してください。
8. LLM が HTML を組み立てることはありません — LLM が生成するのは JSON のみです。テンプレートの組み立ては render_report.py に委任されます。レンダリングに失敗した場合はスキルの失敗です — エラーの理由と対処方法をユーザーに伝えてください。スクリプトを迂回して手動で HTML を出力してはいけません。

---

参考資料

ファイル	目的
references/inspection-commands.md	すべての CLI コマンドと並列バッチのテンプレート
references/degradation-and-validation.md	権限フォールバックの実行順序と JSON の事前検証ルール
references/ram-policies.md	RAM 権限一覧、カスタムポリシー、失敗時の処理
scripts/render_report.py	HTML レンダリングスクリプト（標準ライブラリのみ）
scripts/requirements.txt	scripts/ の正規 Python 依存関係宣言