はじめに
前回の記事では、OpenClaw を Mac Mini にデプロイし、Telegram と Slack の連携を実現しました。Sysdig Secure のセキュリティアラートを Telegram から確認できるようになり、外出先からの運用が格段に楽になりました。
しかし、使い込んでいくうちに新たな課題が見えてきました。
「OpenClaw は個別のツール呼び出しはできるけど、複数ステップにまたがる定型的なワークフローを自動化する手段がない」
たとえば「イベント検知→情報収集→通知→記録」のような一連の処理を毎回 OpenClaw が順にツールを呼び出すのは効率が悪い。ワークフロー自動化プラットフォームを組み込めば、複雑な処理を 1 つのツール呼び出しに集約できるはず——。
そこで目を付けたのが n8n でした。n8n は MCP Server Trigger ノードを備えており、ワークフローを MCP ツールとして公開できます。つまり、OpenClaw から「n8n で○○して」と言うだけで、n8n 上のワークフローが丸ごと実行される。
結論から言うと、これは見事に動きました。しかし、その道のりは予想以上にハマりポイントだらけでした。
実現したこと（Before / After）
Before: 個別ツール呼び出しの世界
- 定型処理はユーザーが毎回手順を指示する必要がある
- 「現在時刻を取得して」のような単純な処理も OpenClaw 自身が処理するしかない
- 外部 API の呼び出しやデータ変換を組み合わせたワークフローが作れない
After: n8n ワークフローエンジン統合
- Telegram で「n8n で現在時刻を取得して」→ 即座に結果が返る
- 「n8n で example.com の内容を取得して」→ Web ページの内容を取得・表示
- n8n の 500+ ノードを使って、今後いくらでもワークフローを追加可能
- MCP ツール呼び出し応答時間: 72ms（curl）/ 264ms（Telegram E2E）
技術的なアプローチ
アーキテクチャ
n8n を Docker コンテナとしてデプロイし、MCP Server Trigger 経由で OpenClaw と接続する構成です。
既存の MCP 統合との違い
ここが今回の統合で最も重要なポイントです。既存の MCP サーバー（Sysdig / draw.io / Serena）はすべて stdio トランスポートを使用していますが、n8n は HTTP トランスポートを使います。
| 項目 | Sysdig / draw.io / Serena | n8n |
|---|---|---|
| トランスポート | stdio（子プロセス起動） | Streamable HTTP |
| 接続先 | stdin/stdout | http://localhost:5678/mcp/openclaw-mcp |
| 認証 | 不要（ローカルプロセス間） | Bearer Token 必要 |
| MCP サーバー管理 | mcp-adapter が都度起動 | Docker が常駐管理 |
Docker コンテナ構成
source ~/.openclaw/.env
docker run -d \
--name n8n \
--restart=always \
-p 127.0.0.1:5678:5678 \
-v /Users/takaos/.n8n:/home/node/.n8n \
-v /etc/ssl/cert.pem:/etc/ssl/certs/host-ca-certificates.crt:ro \
-e N8N_HOST=0.0.0.0 \
-e N8N_PORT=5678 \
-e N8N_PROTOCOL=http \
-e N8N_ENCRYPTION_KEY=${N8N_ENCRYPTION_KEY} \
-e NODE_EXTRA_CA_CERTS=/etc/ssl/certs/host-ca-certificates.crt \
--memory=512m \
--cpus=1.0 \
--health-cmd="wget --spider --quiet http://127.0.0.1:5678/healthz || exit 1" \
--health-interval=30s \
--health-timeout=10s \
--health-retries=3 \
n8nio/n8n:2.9.2
ポイント:
-
-p 127.0.0.1:5678:5678: ローカルホスト限定（外部公開しない） -
--restart=always: Docker Desktop 起動時に自動復帰 - ホスト CA 証明書マウント: SSL 証明書エラー回避（後述）
-
--memory=512m: リソース消費を制限
OpenClaw 側の設定
~/.openclaw/openclaw.json に n8n MCP サーバーのエントリを追加するだけ:
{
"name": "n8n",
"transport": "http",
"url": "http://localhost:5678/mcp/openclaw-mcp",
"headers": {
"Authorization": "Bearer ${N8N_MCP_BEARER_TOKEN}"
}
}
openclaw-mcp-adapter が Streamable HTTP トランスポートをネイティブサポートしていたため、mcp-remote 等のブリッジツールは不要でした。これは嬉しい発見でした。
つまずいたポイントと解決策
今回のデプロイでは、予想外のハマりポイントが次々と現れました。正直、どれも事前のドキュメントだけでは予測できなかったものばかりです。
1. MCP Server Trigger の URL が違う
症状: タスク定義書に記載していた MCP エンドポイント URL /webhook/<path>/mcp にアクセスしても動作しない。
原因: n8n の MCP Server Trigger には typeVersion が存在し、バージョンによって URL 形式が異なります。
| typeVersion | URL 形式 | トランスポート |
|---|---|---|
| 1（レガシー） | /webhook/<path>/mcp |
SSE |
| 2（推奨） | /mcp/<path> |
Streamable HTTP |
n8n 2.9.2 ではデフォルトで typeVersion 2 が使われるため、正しい URL は /mcp/openclaw-mcp でした。
教訓: n8n のノードは typeVersion によって挙動が変わる。MCP Server Trigger を使う場合は typeVersion を確認すること。
2. Code Tool の戻り値の型が違う
症状: MCP の tools/call で get_current_time を呼び出すと、"Wrong output type returned" エラー。
原因: n8n の通常の Code ノードは [{json: {...}}] 形式の配列を返しますが、MCP ツールとして使う Code Tool (AI) は文字列を返す必要があるのです。
// NG: 通常の Code ノードの書き方
return [{json: {currentTime: new Date().toISOString()}}];
// OK: Code Tool (AI) の書き方
const now = new Date();
return JSON.stringify({
currentTime: now.toISOString(),
timezone: Intl.DateTimeFormat().resolvedOptions().timeZone
});
教訓: n8n の Code Tool (AI) は通常の Code ノードと戻り値の型が異なる。MCP ツールとして使う場合は必ず 文字列 を返すこと。
3. ツール接続の方向が逆だった
症状: MCP の tools/list が空（{"tools":[]}）。ワークフローにツールノードを追加したのに認識されない。
原因: n8n のワークフローエディタで、MCP Server Trigger とツールノードの 接続方向が逆 でした。
# NG（直感的だがダメ）
MCP Server Trigger ──→ Code Tool
# OK（正しい方向）
Code Tool ──→ MCP Server Trigger
ツールノードの ai_tool 出力 を MCP Server Trigger の ai_tool 入力 に接続する必要があります。直感に反しますが、「ツールが自分を MCP Trigger に登録する」というイメージです。
教訓: n8n のノード接続は「データフロー」ではなく「登録フロー」として理解する。ツールノードから MCP Trigger への方向が正しい。
4. Docker コンテナ内の SSL 証明書エラー
症状: fetch_webpage ツールで https://example.com を取得しようとすると SSL 証明書エラー。
unable to verify the first certificate
原因: Docker コンテナの CA 証明書バンドルに、一部のサイト（Cloudflare が使用する中間 CA 等）が含まれていなかった。
解決策: ホスト macOS の CA 証明書をコンテナにマウント:
-v /etc/ssl/cert.pem:/etc/ssl/certs/host-ca-certificates.crt:ro
-e NODE_EXTRA_CA_CERTS=/etc/ssl/certs/host-ca-certificates.crt
これにより、ホスト側で信頼されている CA 証明書がコンテナ内の Node.js でも使えるようになりました。
教訓: Docker コンテナ内から HTTPS 通信する場合、ホストの CA 証明書をマウントすると安全かつ確実。Alpine ベースのイメージは特に CA バンドルが最小限なので注意。
5. n8n のサンドボックスで fetch が使えない
症状: Code Tool で fetch('https://...') を使おうとすると "fetch is not defined" エラー。
原因: n8n の Code ノードはサンドボックス内で実行されており、ブラウザやグローバルの fetch API は使えません。
解決策: n8n が提供する this.helpers.httpRequest() を使用:
const response = await this.helpers.httpRequest({
url: inputUrl,
method: 'GET',
returnFullResponse: true,
});
return response.body;
教訓: n8n の Code Tool 内では
fetch、require、importは使えない。HTTP リクエストはthis.helpers.httpRequest()を使う。
成果と効果
パフォーマンス
全ての非機能要件を大幅にクリア:
| 指標 | 目標値 | 計測結果 | 判定 |
|---|---|---|---|
| Web UI 応答速度 | 5 秒以内 | 18ms | PASS |
| MCP ツール呼び出し | 30 秒以内 | 72ms (curl) / 264ms (Telegram E2E) | PASS |
| メモリ使用量 | 500MB 以内 | 229.7 MiB (アイドル時) | PASS |
| 起動時間 | 30 秒以内 | 6.0 秒 | PASS |
特筆すべきは MCP ツール呼び出しの 72ms。ユーザーから見た Telegram E2E でも 264ms と、ほぼリアルタイムにワークフローが実行されます。
登録ツール
現在 2 つのツールを MCP 経由で公開中:
| ツール名 | 説明 |
|---|---|
get_current_time |
現在の日時を UTC と JST で返す |
fetch_webpage |
指定 URL の Web ページ内容を取得して返す |
セキュリティ
-
ローカルホスト限定: n8n は
127.0.0.1のみでリッスン - Bearer 認証: トークンなし/無効トークンでのアクセスは 403 で拒否
-
トークン管理:
~/.openclaw/.env（パーミッション 600）で一元管理 -
リソース制限: Docker
--memory=512mでメモリ上限を設定
運用体制
デプロイと同時に運用ガイドも整備:
- バックアップ手順（SQLite DB + .env + openclaw.json）
- Docker イメージバージョンアップ手順
- Bearer トークンローテーション手順
- トラブルシューティングガイド
全体の作業フロー
5 フェーズ・27 タスクで構成されたデプロイを、約 1 日で完了しました。
| Phase | 名称 | タスク数 | 内容 |
|---|---|---|---|
| A | n8n 基盤構築 | 6 | Docker イメージ取得、コンテナ起動、自動再起動検証 |
| B | MCP Server Trigger 設定 | 5 | ワークフロー作成、認証設定、MCP 単体動作確認 |
| C | OpenClaw 統合 | 6 | mcp-adapter 設定、Gateway 再起動、ツール認識確認 |
| D | ワークフロー作成・検証 | 4 | サンプルツール実装、Telegram テスト、エラーハンドリング |
| E | 運用整備 | 6 | バックアップ、ログ、パフォーマンス計測、運用ガイド作成 |
まとめと今後の展望
まとめ
n8n の MCP Server 統合は、OpenClaw のツール呼び出し能力を大幅に拡張する手段として非常に有効でした。
特に良かった点:
- openclaw-mcp-adapter が Streamable HTTP をネイティブサポートしており、ブリッジ不要で直接接続できた
- Docker コンテナ方式により、ホスト環境を汚さずに安定運用可能
- n8n の Web UI でワークフローをビジュアルに設計・管理できる
- 応答時間 72ms と、ワークフローエンジンを挟んでいるとは思えない速さ
ハマりポイントのまとめ:
- MCP Server Trigger の typeVersion により URL 形式が変わる
- Code Tool (AI) の戻り値 は配列ではなく文字列
- ツールノードの接続方向 は直感に反する（ツール → Trigger）
- Docker コンテナ内の SSL 証明書 はホスト CA のマウントが必要
-
n8n サンドボックス では
fetchが使えずthis.helpers.httpRequest()を使う
これらのハマりポイントは、いずれもドキュメントだけでは予測しにくいものでした。実際に手を動かして初めて分かる類のものです。
今後の展望
n8n の真価はここからです。500+ の公式ノードを活用して、さまざまなワークフローを追加していく予定です:
- セキュリティアラート自動トリアージ: Sysdig アラート → 情報収集 → 重大度判定 → 通知
- 定期レポート生成: 各種データソースから情報を集約し、定期的にレポートを生成
- 外部サービス連携: GitHub、Google Sheets、Notion 等のノードを活用した自動化
- Docker Compose 移行: n8n + Sysdig MCP のコンテナ管理を一元化
OpenClaw + n8n の組み合わせにより、「Telegram で一言指示するだけで複雑なワークフローが実行される」という世界が実現しつつあります。