はじめに
前回の記事で、個人運用型 AI アシスタント OpenClaw を自宅の Mac Mini にデプロイし、Telegram から Slack のセキュリティアラートを参照できる環境を構築しました。
しかし、ある日こんな場面に遭遇しました。
Telegram で「最新のアラート説明して」と聞くと、OpenClaw は Slack に投稿されたアラートメッセージのテキスト情報だけを要約して返してくれます。
「もう少し詳しく知りたい。このイベントのプロセスツリーは？ 関連するプロセスの親子関係は？ 他に似たイベントは発生していない？」
...こういう深掘りには、結局 Sysdig のコンソールを開かなければなりませんでした。
Slack のメッセージテキストからわかる情報には限界があります。アラートの「表面」は見えるけれど、その裏にあるイベント詳細、プロセスツリー、ランタイムイベントの時系列、Kubernetes クラスタの健全性といった「深層データ」にアクセスするには、別途 Sysdig のコンソールにログインする必要がありました。
そこで、Sysdig MCP Server を OpenClaw に統合して、Telegram から直接 Sysdig Secure / Monitor のデータに問い合わせできるようにしました。
この記事では、統合の全工程を Phase A から Phase E まで、ハマったポイントや実際のテスト結果も交えて詳しく紹介します。
Sysdig MCP Server とは？
Sysdig MCP Server は、Sysdig Secure / Monitor の API を MCP（Model Context Protocol） で公開するサーバー実装です。Go で書かれており、Docker イメージとして提供されています（Go バイナリとしての直接実行も可能ですが、今回は Docker 方式を採用しました）。
MCP とは？
MCP（Model Context Protocol）は、LLM とツールの間の標準的な通信プロトコルです。ツールの発見（どんなツールがあるか）、呼び出し（ツールを実行する）、結果返却（結果を受け取る）を統一的に定義しています。
OpenClaw のような AI アシスタントにとって、MCP は「新しい能力を追加するためのプラグインインターフェース」のようなものです。MCP サーバーを接続するだけで、その MCP サーバーが提供するすべてのツールが AI アシスタントのネイティブツールとして使えるようになります。
Sysdig MCP Server が提供する 21 のツール
Sysdig MCP Server v1.0.2 は、以下の 21 ツールを提供します。
Sysdig Secure ツール（5個）:
| ツール名 | 機能 |
|---|---|
list_runtime_events |
ランタイムセキュリティイベントの一覧取得 |
get_event_info |
特定イベントの詳細情報取得 |
get_event_process_tree |
プロセスの親子関係（プロセスツリー）取得 |
run_sysql |
SysQL クエリの直接実行 |
generate_sysql |
自然言語から SysQL クエリを生成・実行 |
Sysdig Monitor ツール（16個）:
| カテゴリ | 主なツール |
|---|---|
| クラスタ管理 | k8s_list_clusters |
| ワークロード | k8s_list_workloads |
| ポッド監視 |
k8s_list_top_unavailable_pods、k8s_list_top_restarted_pods、k8s_list_pod_containers
|
| リソース使用量 |
k8s_list_top_cpu_consumed_workload、k8s_list_top_memory_consumed_workload 等 |
| ノード情報 | k8s_list_nodes |
| エラー検出 |
k8s_list_top_http_errors_in_pods、k8s_list_top_network_errors_in_pods
|
| その他 |
k8s_list_cronjobs、k8s_list_count_pods_per_cluster 等 |
Before / After: 何が変わったのか
Before（Sysdig MCP 統合前）
Sysdig Secure ──→ Slack (#security-alerts) ──→ OpenClaw ──→ テキストベースの要約
（Sysdig API への直接アクセスなし）
OpenClaw は Slack に届いたアラートのメッセージテキストだけを読んで要約していました。「アラートが来ました。内容はこうです」という表面的な対応しかできません。
After（Sysdig MCP 統合後）
┌─────────────────────────────────┐
│ Mac Mini (macOS) │
│ │
Telegram ──→ OpenClaw Gateway ──│→ OpenClaw Agent │
│ ├── 既存ツール群 │
Slack ──→ OpenClaw Gateway ──│→ └── mcp-adapter │
│ └── Sysdig MCP Server │
│ (Docker / stdio) │
└──────────────│──────────────────┘
│
▼ HTTPS (アウトバウンドのみ)
Sysdig Secure / Monitor API
(app.sysdigcloud.com)
OpenClaw は Sysdig の API に直接アクセスして、以下のようなことができるようになりました:
- 「最近のランタイムイベントを見せて」 → 1,612件のイベント一覧を取得
- 「このイベントのプロセスツリーを表示して」 → プロセスの親子関係を階層表示
- 「SysQL で過去1時間のイベントを検索して」 → SysQL クエリを直接実行
- 「Kubernetes クラスタの状態を見せて」 → nuc-home クラスタ（4ノード、42 Pod）の詳細を表示
統合の全工程: Phase A 〜 Phase E
統合作業は 5 つのフェーズ、合計 29 タスクに分けて実施しました。
Phase A: 基盤準備（8タスク）
Docker 環境の確認、Sysdig API トークンの設定、MCP Server の単体動作確認を行うフェーズです。
A-1〜A-3: 環境準備
# Docker 環境確認
docker --version # Docker version 29.2.0
docker info # Platform: linux/arm64, CPUs: 10, Memory: 8GB
# Sysdig API トークンを .env に設定
cat >> ~/.openclaw/.env << 'EOF'
SYSDIG_MCP_API_HOST=https://app.sysdigcloud.com
SYSDIG_MCP_API_TOKEN=<your-token>
SYSDIG_MCP_LOGLEVEL=INFO
EOF
chmod 600 ~/.openclaw/.env
ポイント: Sysdig API トークンは ~/.openclaw/.env に保管し、パーミッションは 600（所有者のみ読み書き可能）に設定します。
A-4〜A-5: Docker イメージの取得と単体動作確認
# Docker イメージの取得（バージョン固定）
docker pull ghcr.io/sysdiglabs/sysdig-mcp-server:v1.0.2
# → arm64 ネイティブイメージ、211MB
単体動作確認では、MCP プロトコルの JSON-RPC メッセージを Docker コンテナの stdin に送信し、ツール一覧が返ってくることを確認しました。
# MCP initialize + tools/list
printf '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{...}}\n{"jsonrpc":"2.0","id":2,"method":"tools/list"}\n' \
| docker run -i --rm \
--memory=512m --cpus=0.5 \
-e "SYSDIG_MCP_API_HOST=${SYSDIG_MCP_API_HOST}" \
-e "SYSDIG_MCP_API_TOKEN=${SYSDIG_MCP_API_TOKEN}" \
-e "SYSDIG_MCP_LOGLEVEL=INFO" \
-e "SYSDIG_MCP_TRANSPORT=stdio" \
ghcr.io/sysdiglabs/sysdig-mcp-server:v1.0.2
確認結果:
- サーバー名:
Sysdig MCP Server、バージョン:v1.0.2 - ツール数: 21個（Secure 5 + Monitor 16）
- コンテナ起動時間: 180ms（非機能要件の 60 秒以内を大幅クリア）
A-6〜A-8: バージョン固定・自動起動・リソース制限
- Docker イメージは
:latestではなく:v1.0.2タグで固定（破壊的変更を回避） - Docker Desktop の自動起動を有効化（Mac ログイン時に自動的に Docker が起動）
- リソース制限
--memory=512m --cpus=0.5で正常動作を確認（OOM Kill なし）
Phase B: OpenClaw 統合（5タスク）
Sysdig MCP Server を OpenClaw のエコシステムに接続するフェーズです。
B-1: mcp-adapter プラグインのインストール（ハマりポイント①）
OpenClaw に MCP サーバーを統合するには、mcp-adapter プラグインが必要です。
# 通常のインストール方法（...しかし失敗する）
openclaw plugins install mcp-adapter
# → Error: package.json missing openclaw.extensions
npm パッケージの package.json に必要なフィールドが不足しているため、通常のインストールが失敗します。
回避策: ソースコードから直接インストール
git clone https://github.com/androidStern-personal/openclaw-mcp-adapter.git /tmp/openclaw-mcp-adapter
openclaw plugins install /tmp/openclaw-mcp-adapter
# → 成功
B-2〜B-3: openclaw.json の設定
~/.openclaw/openclaw.json に以下を追加します。
{
"plugins": {
"entries": {
"openclaw-mcp-adapter": {
"enabled": true,
"config": {
"servers": [{
"name": "sysdig",
"transport": "stdio",
"command": "docker",
"args": [
"run", "-i", "--rm",
"--memory=512m", "--cpus=0.5",
"-e", "SYSDIG_MCP_API_HOST",
"-e", "SYSDIG_MCP_API_TOKEN",
"-e", "SYSDIG_MCP_LOGLEVEL",
"-e", "SYSDIG_MCP_TRANSPORT=stdio",
"ghcr.io/sysdiglabs/sysdig-mcp-server:v1.0.2"
],
"env": {
"SYSDIG_MCP_API_HOST": "${SYSDIG_MCP_API_HOST}",
"SYSDIG_MCP_API_TOKEN": "${SYSDIG_MCP_API_TOKEN}",
"SYSDIG_MCP_LOGLEVEL": "${SYSDIG_MCP_LOGLEVEL}"
}
}]
}
}
}
},
"tools": {
"sandbox": {
"tools": {
"allow": ["mcp-adapter"]
}
}
}
}
設定のポイント:
-
transport: "stdio"— Docker コンテナを子プロセスとして起動し、stdin/stdout で通信（ネットワークポート不要） -
--rm— コンテナは使い捨て。リクエストごとに起動・終了 -
envブロック —.envファイルの環境変数を Docker コンテナに渡す -
tools.sandbox.tools.allow— mcp-adapter のツール使用を許可
B-4〜B-5: Gateway 再起動とツール認識確認
# Gateway 再起動
launchctl kickstart -k gui/$(id -u)/ai.openclaw.gateway
# ヘルスチェック
openclaw doctor
# → Plugins Loaded: 7, Errors: 0
Telegram から OpenClaw にツール一覧を確認したところ、21 個の Sysdig ツールがすべて sysdig_ プレフィックス付きで認識されていました。
Sysdig Secure:
- sysdig_list_runtime_events
- sysdig_get_event_info
- sysdig_get_event_process_tree
- sysdig_run_sysql
- sysdig_generate_sysql
Sysdig Monitor:
- sysdig_k8s_list_clusters
- sysdig_k8s_list_workloads
- sysdig_k8s_list_nodes
... 他 13 ツール
Phase C: Secure ツール検証（5タスク）
Sysdig Secure の 5 つのツールを、実際に Telegram から使って検証しました。
C-1: ランタイムイベント一覧
Telegram で「最近のランタイムセキュリティイベントを見せて」と送信。
OpenClaw の応答（抜粋）:
過去24時間で 1,612 件のセキュリティイベントが検出されました。
主なイベント:
- nuc1〜nuc4: Read sensitive file trusted / untrusted
重大度: Medium〜High
対象ファイル: /etc/shadow
- K8s Audit: K8s リソースへのアクセスイベント
重大度: Info
クラスタ: nuc-home（4ノード）
1,612 件のイベントが取得され、ノード別・重大度別に整理されて返ってきました。
C-2: イベント詳細
特定のイベント ID を指定して詳細を取得。
OpenClaw の応答:
ルール名: Sysdig Runtime Notable Events
重大度: High (Severity 4)
MITRE ATT&CK: Discovery > System Information Discovery
コンプライアンス: NIST 800-53, PCI DSS, SOC2
コンテナ情報: ホストイベント（nuc1）
実行コマンド: mkinitramfs -o /boot/initrd.img-6.8.0-60-generic 6.8.0-60-generic
MITRE ATT&CK の分類やコンプライアンスタグまで取得できます。これは Slack のテキストアラートだけでは得られない情報です。
C-3: プロセスツリー
OpenClaw の応答:
プロセスツリー:
systemd (PID: 1)
└── cron (PID: 891)
└── sh (PID: 12345)
└── run-parts (PID: 12346)
└── update-initramfs (PID: 12347)
└── mkinitramfs (PID: 12348)
└── find (PID: 12349)
└── cat /etc/shadow (PID: 12350)
プロセスの親子関係が階層的に表示され、「cron → run-parts → update-initramfs → mkinitramfs → cat /etc/shadow」 という一連の流れが明確に把握できました。これにより、このイベントが定期的なシステムメンテナンス（initramfs の更新）に伴う正当なアクセスであることが即座に判断できます。
C-4: SysQL クエリ実行
ユーザー: 「SysQL で過去1時間のランタイムイベントを検索して」
OpenClaw: run_sysql ツールで直接クエリを実行しました:
SELECT timestamp, severity, ruleName, hostName
FROM sysdig_secure_events
WHERE timestamp >= NOW() - INTERVAL '1 HOUR'
ORDER BY timestamp DESC
SysQL（Sysdig の SQL ライクなクエリ言語）を直接実行できます。実行結果はテーブル形式で整形されて返ってきます。
C-5: SysQL 自然言語生成（generate_sysql）
ユーザー: 「コンテナ内で実行された curl コマンドを探す SysQL を作って」
OpenClaw: generate_sysql ツールで SysQL を生成・実行しました:
生成されたクエリ:
SELECT timestamp, hostName, containerName, commandLine
FROM sysdig_secure_events
WHERE commandLine LIKE '%curl%'
AND containerName IS NOT NULL
ORDER BY timestamp DESC
自然言語から SysQL クエリを自動生成してくれます。SysQL の構文を知らなくても、日本語で「何を探したいか」を伝えるだけで適切なクエリが生成されます。
補足: Sysdig 公式ドキュメントでは generate_and_run_sysql（生成+実行）と記載されている箇所がありますが、実際のツール名は generate_sysql です（GitHub README 準拠、Phase A の動作確認で検証済み）。
Phase D: Monitor ツール検証（7タスク）
Phase D は、最大のハマりポイントが発見されたフェーズです。
API エンドポイントの罠（ハマりポイント②）
Phase C の Secure ツールは問題なく動作していましたが、Phase D で Monitor ツール（k8s_list_clusters 等）を実行すると、API エラーが返ってきました。
エラー: failed to decode response: invalid character '<' looking for beginning of value
「< で始まる無効な文字」— これは JSON ではなく HTML が返ってきていることを意味します。
原因の調査:
Sysdig の US East リージョンには、実は2つのエンドポイントが存在します:
| エンドポイント | 対応する機能 |
|---|---|
secure.sysdig.com |
Sysdig Secure のみ |
app.sysdigcloud.com |
Sysdig Secure + Monitor 両方 |
当初 SYSDIG_MCP_API_HOST=https://secure.sysdig.com と設定していたため、Secure ツールは動作していましたが、Monitor ツールは secure.sysdig.com では処理できず、HTML エラーページが返されていたのです。
解決策:
# ~/.openclaw/.env を修正
SYSDIG_MCP_API_HOST=https://app.sysdigcloud.com
app.sysdigcloud.com は Secure と Monitor の両方が動作する統合エンドポイントです。この変更後、すべての Monitor ツールが正常動作するようになりました。
教訓: Sysdig のリージョンドキュメントでは Secure と Monitor で異なる URL が記載されています。MCP Server のように両方の API を使うツールでは、統合エンドポイント（app.sysdigcloud.com）を使用する必要があります。これは公式ドキュメントのどこにも明記されていないため、実装時に自ら発見する必要がありました。
D-1〜D-7: Monitor ツールの動作確認
エンドポイント修正後、全 Monitor ツールが正常動作しました。
ユーザー: 「Kubernetes クラスタの状態を見せて」
OpenClaw の応答:
クラスタ: nuc-home
Kubernetes バージョン: v1.32.7
ノード数: 4（nuc1, nuc2, nuc3, nuc4）
Pod 数: 42
Namespace 数: 6
各ノード:
- nuc1: Ubuntu 22.04.5 LTS, containerd 1.7.27
- nuc2: Ubuntu 22.04.5 LTS, containerd 1.7.27
- nuc3: Ubuntu 22.04.5 LTS, containerd 1.7.27
- nuc4: Ubuntu 22.04.5 LTS, containerd 1.7.27
ユーザー: 「CPU を最も消費しているワークロードは？」
OpenClaw の応答:
CPU 使用量 Top 5:
1. shield-host (DaemonSet): 0.85 cores
2. coredns (Deployment): 0.12 cores
3. shield-proxy (DaemonSet): 0.08 cores
4. calico-node (DaemonSet): 0.07 cores
5. metrics-server (Deployment): 0.03 cores
合計: 約 1.4 cores（4ノード全体）
ユーザー: 「再起動が多いポッドはどれ？」
OpenClaw の応答:
頻繁に再起動しているポッドは見つかりませんでした。
すべてのポッドが安定して稼働しています。
このように、Telegram から K8s クラスタの健全性監視が完全にできるようになりました。
Phase E: 運用整備（4タスク）
最後に、安定運用のための整備を行いました。
E-1: バックアップスクリプト更新
既存のバックアップスクリプトに、mcp-adapter プラグインのバックアップを追加しました。
# ~/openclaw-backups/backup.sh に追加
# mcp-adapter プラグイン（Sysdig MCP Server 統合）
cp -r ~/.openclaw/extensions/openclaw-mcp-adapter "$BACKUP_DIR/" 2>/dev/null
E-2〜E-3: ログ設定とトークンローテーション
- ログレベルは
INFOに設定（通常運用時）。トラブルシューティング時はDEBUGに変更可能 - API トークンのローテーション手順を文書化
E-4: 全体動作検証
2つの重要なテストを実施しました。
T-MCP-07: 既存機能影響なしテスト
Sysdig MCP 統合後も、既存の OpenClaw 機能が正常に動作することを確認しました。
| チャネル | テスト内容 | 結果 |
|---|---|---|
| Telegram | 通常の会話（天気情報取得） | 正常動作 |
| Slack | 通常の会話（天気情報取得） | 正常動作 |
| クロスチャネル | Telegram → Slack 履歴参照 | 正常動作 |
T-MCP-08: 障害時分離テスト
Sysdig MCP Server（Docker）に障害が発生しても、OpenClaw の既存機能が影響を受けないことを確認しました。
| ステップ | 操作 | 結果 |
|---|---|---|
| 1 | Docker Desktop を停止 | Sysdig ツールは接続エラーを返却 |
| 2 | Telegram で通常会話 | 正常動作（影響なし） |
| 3 | Slack で通常会話 | 正常動作（影響なし） |
| 4 | Docker Desktop を再起動 | Sysdig ツールが自動復帰 |
Docker が停止しても OpenClaw の通常機能には一切影響がなく、Docker 再起動後は Sysdig ツールが自動的に復帰しました。MCP アダプターの障害分離設計が正しく機能しています。
全テスト結果
10 の受入テストシナリオをすべて実施し、全テスト合格を確認しました。
| テストID | テスト名 | 結果 |
|---|---|---|
| T-MCP-01 | Sysdig MCP Server 接続テスト | PASS |
| T-MCP-02 | OpenClaw ツール認識テスト | PASS |
| T-MCP-03 | ランタイムイベント取得テスト | PASS |
| T-MCP-04 | イベント詳細・プロセスツリー取得テスト | PASS |
| T-MCP-05 | SysQL クエリ実行テスト | PASS |
| T-MCP-05a | SysQL 自然言語生成テスト | PASS |
| T-MCP-06 | Kubernetes クラスタ情報取得テスト | PASS |
| T-MCP-07 | 既存機能影響なしテスト | PASS |
| T-MCP-08 | 障害時分離テスト | PASS |
| T-MCP-09 | Kubernetes Monitor ツール群テスト | PASS |
ハマったポイント Top 3
1. API エンドポイントの罠（Phase D）— 最大のハマりポイント
Sysdig の US East リージョンには secure.sysdig.com（Secure 専用）と app.sysdigcloud.com（Secure + Monitor 統合）の 2 つのエンドポイントがあり、MCP Server では統合エンドポイントを使う必要があるという情報がどこにも書かれていませんでした。
Phase C の Secure ツールが正常動作していたため、最初は「Secure と Monitor で別のトークンが必要なのでは？」と疑い、かなり遠回りしました。実際には、エンドポイント URL を app.sysdigcloud.com に変更するだけで解決しました。
判断の決め手: API エラーメッセージが invalid character '<'（HTML レスポンス）だったこと。JSON を期待している API に HTML が返ってきているということは、「正しい API サーバーに接続できていない」ことを示唆していました。
2. mcp-adapter の npm パッケージ問題（Phase B）
openclaw plugins install mcp-adapter が package.json missing openclaw.extensions エラーで失敗します。npm パッケージの package.json に OpenClaw プラグインとして必要なフィールドが不足しているためです。
回避策: GitHub からソースコードを clone して、ローカルパスからインストール。
git clone https://github.com/androidStern-personal/openclaw-mcp-adapter.git /tmp/openclaw-mcp-adapter
openclaw plugins install /tmp/openclaw-mcp-adapter
3. Docker stdin パイプの環境変数受け渡し（Phase A）
MCP Server の単体動作確認時、echo ... | docker run -i --rm -e SYSDIG_MCP_API_HOST="${VAR}" ... でコンテナが起動するものの、「required configuration missing: SYSDIG_MCP_API_HOST」というエラーが発生しました。
パイプ経由で Docker を実行する際、環境変数の受け渡しには -e "SYSDIG_MCP_API_HOST=${SYSDIG_MCP_API_HOST}" のように全体を二重引用符で囲む必要があります。
技術的な知見
統合作業を通じて得られた技術的な知見をまとめます。
Docker コンテナ起動時間: 180ms
Sysdig MCP Server は Go で実装されているため、Docker コンテナの起動が非常に高速です。ツール呼び出しのたびにコンテナを起動・終了する --rm 方式でも、ユーザーにとって体感的な遅延はほぼありません。
stdio トランスポートのセキュリティ優位性
MCP Server は SSE（Server-Sent Events）や HTTP トランスポートにも対応していますが、今回は stdio（標準入出力） トランスポートを選択しました。
- ポート開放不要: ネットワークからのアクセスを完全に排除
- プロセス分離: Docker コンテナ内で実行されるため、ホスト環境への影響を最小化
-
リソース制限:
--memory=512m --cpus=0.5でコンテナのリソース使用量を制御
ツール命名規則: sysdig_ プレフィックス
mcp-adapter は toolPrefix オプション（デフォルト: true）により、サーバー名をプレフィックスとして付与します。name: "sysdig" と設定すると、list_runtime_events は sysdig_list_runtime_events として OpenClaw に登録されます。
これにより、複数の MCP サーバーを接続した場合でもツール名が衝突しません。
Sysdig の Severity 体系
Sysdig のイベント重大度は 数値が低いほど重大です。一般的なログレベル（数値が高いほど重大）とは逆なので注意が必要です。
| 数値 | 重大度 |
|---|---|
| 0-1 | Critical |
| 2-3 | High |
| 4-5 | Medium |
| 6 | Low |
| 7 | Info |
まとめ
実現したこと
Sysdig MCP Server を OpenClaw に統合することで、Telegram から自然言語で Sysdig Secure / Monitor のデータに直接アクセスできるようになりました。
| 機能 | 具体例 |
|---|---|
| ランタイムイベント深掘り | 「このイベントのプロセスツリーを見せて」→ 親子関係を階層表示 |
| 自然言語 SysQL | 「curl を実行したコンテナを探して」→ SysQL を自動生成・実行 |
| K8s 可視性 | 「CPU を最も消費しているワークロードは？」→ リソース使用量 Top N |
| 障害分離 | Docker 停止時も既存のチャット機能は正常動作 |
技術スタック
| コンポーネント | バージョン / 詳細 |
|---|---|
| OpenClaw | 2026.2.9 |
| Sysdig MCP Server | v1.0.2 (Docker) |
| mcp-adapter | ソースインストール |
| Docker | 29.2.0 (arm64) |
| API エンドポイント | app.sysdigcloud.com |
| ホスト | Mac Mini (macOS 26.1) |
今後の展望
- Sysdig MCP Server のバージョンアップ追従: v1.0.2 からの新機能を取り込み
- ワークスペースプロンプト改善: Sysdig データを活用した初動提案の精度向上
- アラート → 深掘り自動化: Slack アラート受信時に自動的にプロセスツリーまで取得する仕組みの検討
- 他の MCP サーバーの統合: GitHub MCP Server や Prometheus MCP Server などの追加接続