OpenClaw + n8n ワークフローオーケストレーション

AIエージェントにAPIキーを直接管理させ、外部サービスをcallさせることはセキュリティインシデントの处方です。新しい統合ごとに .env.local に別の資格情報が必要になり、エージェントが誤って漏洩または悪用する別の поверхностьが増えます。

このユースケースでは、OpenClawがすべての外部APIインタラクションをwebhook経由でn8nワークフローにdelegateするパターンを説明します — エージェントは資格情報に触れず、すべての統合は視覚的に検査可能でロック可能です。

課題点

OpenClawがすべてを直接処理するとき、3つの複合問題が発生します：

• 可視性の欠如: エージェントが実際に何を構築したかを検査することは、JavaScriptスキルファイルやシェルスクリプトに埋もれているときに難しい
• 資格情報の拡散: すべてのAPIキーがエージェントの環境にあり、悪いコミットで漏洩するリスクがある
• トークンの浪費: 決定論的なサブタスク（メール送信、スプレッドシート更新）は、シンプルなワークフローとして実行できるときにLLM推論トークンを消費する

できること

• プロキシパターン: OpenClawは着信webhookを持つn8nワークフローを作成し、将来すべてのAPIインタラクションのためにそれらのwebhookをcall
• 資格情報の分離: APIキーはn8nの資格情報ストアに存在します — エージェントはwebhook URLのみを知っています
• 視覚的なデバッグ: 各ワークフローはn8nのドラッグアンドドロップUIで検査可能です
• ロック可能なワークフロー: ワークフローが構築されてテストされたら、エージェントがAPIとの対話方法を変更できないようにロックします
• 保護ステップ: 外部callが実行される前に、n8nで検証、レート制限、承認ゲートを追加できます

動作方法

1. エージェントがワークフローを設計: OpenClawに何を必要かを伝えます（例：「新しいGitHub issueにurgentラベルが付けられたときにSlackメッセージを送信するワークフローを作成」）
2. エージェントがn8nで構築: OpenClawは着信webhookトリガーを含むn8nのAPI経由でワークフローを作成
3. あなたが資格情報を追加: n8nのUIを開き、手動でSlackトークン/GitHubトークンを追加
4. ワークフローをロック: エージェントによるさらなる変更を防止
5. エージェントがwebhookをcall: 以後、OpenClawはJSONペイロードでhttp://n8n:5678/webhook/my-workflowをcall — APIキーは見ません

┌──────────────┐     webhook call      ┌─────────────────┐     API call     ┌──────────────┐
│   OpenClaw   │ ───────────────────→  │   n8n Workflow   │ ─────────────→  │  External    │
│   (agent)    │   (no credentials)    │  (locked, with   │  (credentials   │  Service     │
│              │                       │   API keys)      │   stay here)    │  (Slack, etc)│
└──────────────┘                       └─────────────────┘                  └──────────────┘

必要なスキル

• n8n APIアクセス（ワークフロー作成/トリガー用）
• webhook call用のfetchまたはcurl
• Docker（事前構成されたスタックを使用する場合）
• n8n資格情報管理（手動、統合ごとに一回限りのセットアップ）

セットアップ方法

オプション1：事前構成されたDockerスタック

コミュニティでメンテナンスされているDocker Composeセットアップ（openclaw-n8n-stack）は共有Dockerネットワークですべてを事前配線します：

git clone https://github.com/caprihan/openclaw-n8n-stack.git
cd openclaw-n8n-stack
cp .env.template .env
# Add your Anthropic API key to .env
docker-compose up -d

これにより以下が得られます：

• ポート3456のOpenClaw
• ポート5678のn8n
• OpenClawが直接http://n8n:5678/webhook/...をcallできる共有Dockerネットワーク
• 事前構築されたワークフローテンプレート（マルチLLMファクトチェック、メールトリアージ、ソーシャルモニタリング）

オプション2：手動セットアップ

1. n8nをインストール（npm install n8n -g またはDocker経由で実行）
2. OpenClawがn8nのベースURLを知るように構成
3. AGENTS.mdに追加：

## n8n 統合パターン

外部APIと対話する必要があるとき：

1. APIキーを私の環境やスキルファイルに保存しないでください
2. この統合用のn8nワークフローが既に存在するかどうかを確認
3. なければ、webhookトリガーを含むn8n API経由で作成
4. ユーザーが資格情報を追加し、ワークフローをロックすることを通知
5. 将来すべてのcallには、JSONペイロードでwebhook URLを使用

ワークフロー命名：openclaw-{service}-{action}
例：openclaw-slack-send-message

Webhook call形式：
curl -X POST http://n8n:5678/webhook/{workflow-name} \
  -H "Content-Type: application/json" \
  -d '{"channel": "#general", "message": "Hello from OpenClaw"}'

重要な洞察

• 一石三鳥: 可視性（視覚的UI）、セキュリティ（資格情報の分離）、パフォーマンス（決定論的なサブタスクはトークンを消費しない）
• テスト後にロック: 「構築 → テスト → ロック」サイクルは重要です — ロックなしでは、エージェントはワークフローを静かに変更できます
• n8nは400以上の統合を持つ: 接続したいほとんどの外部サービスには既にn8nノードがあり、エージェントがカスタムAPIコールを書くことを節約
• 無料での監査証跡: n8nは入力/出力データで各ワークフロー実行をログ

触発されたもの

このパターンはSimon Høibergによって説明されました。彼は、OpenClawがAPIインタラクションを直接処理させることを打ち負かす3つの理由を概説しました：n8nの視覚的UIを通じた可視性、資格情報の分離によるセキュリティ、決定論的なサブタスクをLLM callではなくワークフローとして実行することによるパフォーマンス。openclaw-n8n-stackリポジトリはこのパターンを実装する実行可能なDocker Composeセットアップを提供します。

関連リンク

• n8nドキュメント
• openclaw-n8n-stack（Dockerセットアップ）
• n8n Webhookトリガードキュメント