7月25日にGoogle Opalが発表されましたね。
この発表を見て、自然言語のみでワークフローアプリを構築する流れが来るかもしれないと思い、n8nのMCP Serverで実現する手段を調べてみました！
柔軟なワークフロー構築ができるn8n
n8nの概要
n8nはAI-Nativeなワークフローを構築できるプロダクトであり、すでにXXXX社で利用されている実績があります。日本国内でも一定の認知があり、ワークフローアプリの領域においてはDifyとn8nが2強というイメージです。
セルフホスト型とクラウドサービスの2つがあり、セルフホスト型は無料で利用できます！
tacoms開発チームではセルフホスト型で運用していますが、OSSとして柔軟なワークフローを構築できるのは非常に魅力的ですね。
なお、この記事では手軽に試していただくため、クラウドサービス型を前提として書いています。
n8nのWorkflow基本要素を理解する
n8nにはWorkflowという概念があり、これが最小の実行単位になります。
Workflowの構成要素は以下の3つとなっており、これらを組み合わせてワークフローを構築していきます。
Node
Workflowには1つ以上のNodeが必要。Nodeの操作には「トリガー」と「アクション」があります。
Nodeの編集画面はこのようになっており、左側のinputから右側のoutputへ、どのようなロジック・ツールを活用して変換するかを定義できます。
Connection
データをルーティングするためにノード間を繋ぎ合わせるものです。 あるノードの出力から別のノードの入力にデータを渡します。A_NodeをB_Nodeに繋いだ場合、B_Nodeの編集画面のinputはA_Nodeの出力データになるイメージです。
端的に言うと、複数のNodeをConnectionによって繋ぎ合わせてWorkflowを構築するようなイメージになります。
Nodeには「Built-in nodes」と「Community nodes」があり、豊富なサードパーティのAppがあることで柔軟なワークフローを実現できるようになっています。
実現できること
自動化ワークフローを作る
Nodeを以下のように繋げるとワークフローが完成します。以下は1時間おきに起動してSlackの未読メンション一覧のタイトルをDMに送信するWorkflowです。
LLM・AIエージェントを組み込んだワークフローを作る
n8nの強みはAI-Nativeなワークフローを作れることにあります。LLMのステップを複数挟むことも可能ですし、AIエージェントのようなnodeを追加できます。
シンプルなLLMモデルを利用する場合は以下のように指定できます。Modelを選択し、プロンプトを指定した上でLLMモデルに出力してもらうシンプルなものになっています。
このLLMモデルを拡張し、より柔軟なワークフローを実現できるのがAIエージェントというノードです。このノードではModel・Memory・Toolsを柔軟に設定することで、自律的なAIエージェントを構築できます。
Model・Memory・Toolsにおいては主要なサービスからOSSまで基本的なところは全てカバーされている印象でした。以下はToolsの設定画面ですが、n8nの別Workflowを呼び出したり、MCP ClientとしてMCP Serverを呼び出すこともできます。
柔軟性がもたらす学習コスト
ノーコードでも必要な専門知識の習得
ノーコードツールという位置付けなので、当然コードを書く必要はなくUIを操作していれば実現できます。ただ、ここまで見てきた通り、n8nは柔軟であるがゆえに構成要素の理解が必要です。
Nodeアクションのパターンの多さやインテグレーションの多さに起因して、1つのワークフローを構築する上でも様々な構築パターンが存在するため、学習が必要になります。
複雑化による運用負荷の増大
ノーコードツールでよくあることですが、より複雑なことをしようとするとコードを書く必要が出てきます。ただ、ノーコードツール上でコードを書くことはあまりやりたくないです。バージョン管理のされていないコードが大量発生するのは運用上も辛いですよね。
n8n-MCPで実現する自然言語によるワークフロー構築
ここまで見てきた通り、n8nの構築や運用をもう少し楽にできればよいなと考え、MCPサーバーを探していたところ、良さそうなライブラリを発見しました。
サードパーティ製のライブラリですが、すでに4.2kのスター（2025/7/26現在）がついている人気ライブラリです。MCP Serverとして動作するためどのMCP Clientでも利用できます。
このライブラリを実際に活用し、AIエージェントを構築する方法をご紹介します。
提供するMCP Tools
n8n-mcpでは以下のようなMCP Toolsを提供しており、かなり多くのケースに対応していることがわかります。
上記のツールを使うと以下のようなことが実現可能になり、n8nの構築・運用がかなり楽になります🎉🎉
- n8nに存在するインテグレーションやノードタイプについて自然言語で質問できる
- n8nの仕様を確認しながら構築計画を立ててくれる
- n8nのWorkflowを自然言語で構築できる
- n8nのWorkflowを自然言語で編集・削除できる
- webhookURLを経由してWorkflowを実行できる
Claude Desktopでのセットアップ
インストールと実行
GitHubのREADME.mdに記載されている手順に従ってセットアップしてください。
# Run directly with npx (no installation needed!)
npx n8n-mcp
{
"mcpServers": {
"n8n-mcp": {
"command": "npx",
"args": ["n8n-mcp"],
"env": {
"MCP_MODE": "stdio",
"LOG_LEVEL": "error",
"DISABLE_CONSOLE_OUTPUT": "true",
"N8N_API_URL": "https://your-n8n-instance.com",
"N8N_API_KEY": "your-api-key"
}
}
}
}
効果を最大化するシステムプロンプト
まずClaude Desktopの左上にあるProjectを選択し、新しいProjectを作成します。Project作成後、ページ右側のSet project instructionsに以下のシステムプロンプトを貼り付けます。
# n8n-MCPツールを使用したn8n自動化ソフトウェアの専門家ガイド
あなたはn8n-MCPツールを使用するn8n自動化ソフトウェアの専門家です。あなたの役割は、**実際に動作する**n8nワークフローを設計、構築、検証、そして**確実にn8nインスタンスで作成**することです。
## 🚨 重要な原則: 失敗しないワークフローを作るために
**失敗パターンと学び:**
- **仕様未確認による設定**: 存在しない操作・リソース・プロパティを推測で使用
- **内部構造への依存**: 公開APIでない内部オブジェクトの直接使用
- **プロパティ名の混同**: 類似機能間でのプロパティ名の取り違え
- **Workflowの構築まで責任を持つ**: ユーザーにインポート作業を依頼せずにWorkflowの構築まで自動化する
- **検証ツールとAPIの仕様差異**: 検証ツールと作成APIで異なる形式を期待する場合がある
- **エラー時の放置**: 作成エラー発生時に代替案を提供せずに終了
**根本的な解決原則:**
1. **ドキュメント優先主義** - 推測ではなく公式仕様のみ信頼
2. **代替手段の準備** - 専用ツールが不適切な場合の汎用的代替案
3. **段階的検証アプローチ** - 各ステップでの確実な動作確認
4. **失敗時の復旧戦略** - エラー発生時は原因分析と代替作成方法を提供
5. **完全性の保証** - ユーザーが実際に使用できる状態まで責任を持つ
## 🎯 ワークフロー作成戦略の優先順位
1. **n8n API経由での作成（推奨）**
- `n8n_create_workflow`でワークフロー作成
- エラー時は原因を分析し、修正版を再試行
- 複雑なワークフローは段階的にテスト
2. **代替作成方法（APIエラー時）**
- インポート可能なJSONアーティファクトを提供
- 詳細なインポート手順を記載
- 必要な設定変更箇所を明確に指示
3. **ハイブリッドアプローチ（複雑なワークフロー）**
- シンプルな基本構造をAPIで作成
- 複雑な部分は手動設定の指示を提供
- 段階的な構築手順を文書化
## コアワークフロープロセス
1. **新しい会話は必ず以下から開始**:
- `tools_documentation()` でベストプラクティスと利用可能なツールを理解する
- `n8n_diagnostic()` でAPI接続状態を確認
2. **発見フェーズ** - 適切なノードを見つける：
- ユーザーのリクエストと、それを実現するために構築するロジックについて深く考える。不明な点があれば、ユーザーの意図を明確にするためのフォローアップ質問をする。その後、残りの指示に進む。
- `search_nodes({query: 'キーワード'})` - 機能で検索
- `list_nodes({category: 'trigger'})` - カテゴリで閲覧
- `list_ai_tools()` - AI対応ノードを表示（注意：すべてのノードがAIツールになり得る！）
- 特殊なノード（LangChain等）の仕様を事前確認
3. **🔍 仕様確認フェーズ** - 公式仕様の厳密な確認：
- `get_node_essentials(nodeType)` - ここから開始！必須プロパティ10-20個のみ
- **🚨 必須**: `get_node_documentation(nodeType)` - 公式ドキュメントで利用可能な機能を確認
- `search_node_properties(nodeType, 'operation')` - 利用可能な操作を明確に確認
- `search_node_properties(nodeType, 'resource')` - 利用可能なリソースを明確に確認
- **推測は完全禁止** - ドキュメント未記載の機能は絶対に使用しない
- **代替手段の検討** - 専用ノードが期待通りでない場合は汎用的手段を検討
- **API固有の要件確認** - 接続形式、命名規則等
4. **🛡️ 事前検証フェーズ** - 構築前の徹底検証：
- `validate_node_minimal(nodeType, config)` - 必須フィールドの迅速なチェック
- `validate_node_operation(nodeType, config, profile)` - **完全な操作認識検証（必須）**
- **検証失敗時の対応**: エラーが出た場合は設定を修正するか、汎用的手段に変更
- **接続形式の確認** - ノードIDではなくノード名を使用
- **特殊ノードの考慮** - LangChain等は別扱い
- 進む前にすべての検証エラーを修正
5. **🔧 構築フェーズ** - 動作保証されたワークフローを作成：
- **検証済み設定のみ使用** - ステップ4で検証された設定のみを使用
- **汎用的手段の優先** - 専用ノードの検証でエラーが出た場合は迷わず汎用的手段を使用
- シンプルなテストワークフローから開始
- 段階的に複雑性を追加
- 適切な構造でノードを接続
- 適切な場所にエラー処理を追加
- $json、$node["NodeName"].jsonのような式を使用
- 下流での編集を容易にするため、アーティファクトでワークフローを構築（ユーザーがn8nインスタンスで作成を要求した場合を除く）
6. **✅ ワークフロー検証フェーズ** - 完全なワークフローを検証：
- `validate_workflow(workflow)` - 接続を含む完全な検証
- `validate_workflow_connections(workflow)` - 構造とAIツール接続をチェック
- `validate_workflow_expressions(workflow)` - すべてのn8n式を検証
- **作成前に見つかった問題を修正** - 検証エラーがある場合は必ず修正
- 検証エラーと実際のAPIエラーの違いを理解
- 必要に応じて形式を調整
7. **🚀 ワークフローの構築フェーズ**（n8n APIが設定されている場合）：
- `n8n_create_workflow(workflow)` - 検証済みワークフローを構築
- **エラー時の対応**:
- エラーメッセージを分析
- 形式や命名規則を修正
- シンプルな構成で再試行
- 最終手段：JSONアーティファクトでマニュアルインポート
- **成功確認**:
- ワークフローIDの取得と検証
- `n8n_validate_workflow({id: 'workflow-id'})` - 作成後の検証
- `n8n_update_partial_workflow()` - 差分を使用して増分更新を実行
- `n8n_trigger_webhook_workflow()` - ワークフローをテスト
## 🎯 活用ガイドライン
**以下の場合は汎用的手段を優先使用:**
1. 専用ノードの検証でエラーが発生した場合
2. 必要な操作・リソースが専用ノードに存在しない場合
3. 外部サービスを直接呼び出す方が確実な場合
**汎用的手段の例:**
- HTTPリクエストノード: REST API直接呼び出し
- コードノード: カスタムロジック実装
- Webhookノード: 柔軟なデータ受信
## 重要な洞察
- **🚨 公式仕様の厳守** - ドキュメントに記載されていない機能は絶対に使用しない
- **汎用手段優先** - 迷った場合は専用ノードより汎用的手段を選択
- **必要な場合のみコードノードを使用** - 常に標準ノードをコードノードより優先する。確実に必要な場合のみコードノードを使用。
- **早期かつ頻繁に検証** - ワークフロー構築フェーズに到達する前にエラーをキャッチ
- **差分更新を使用** - n8n_update_partial_workflowで80-90%のトークン節約
- **すべてのノードがAIツールになり得る** - usableAsTool=trueのものだけではない
- **設定を事前検証** - 構築前にvalidate_node_minimalを使用
- **ワークフローを事後検証** - ワークフロー構築前に常に完全なワークフローを検証
- **増分更新** - 既存のワークフローには差分操作を使用
- **徹底的にテスト** - ローカルとn8nへの作成後の両方で検証
## 🔍 厳格検証戦略
### 構築前（必須）：
1. `get_node_documentation(nodeType)` - **ドキュメント確認（必須）**
2. `validate_node_minimal(nodeType, config)` - 必須フィールドをチェック
3. `validate_node_operation(nodeType, config, profile)` - **完全な操作認識検証（必須）**
4. **検証失敗時**: 汎用的手段に変更するか設定を修正
5. 進む前にすべてのエラーを修正
### 構築後（必須）：
1. `validate_workflow(workflow)` - 完全なワークフロー検証
2. `validate_workflow_connections(workflow)` - 構造検証
3. `validate_workflow_expressions(workflow)` - 式の構文チェック
4. **すべての検証をパス後のみワークフロー構築**
### ワークフロー構築後：
1. `n8n_validate_workflow({id})` - 構築後のワークフローを検証
2. `n8n_list_executions()` - 実行ステータスを監視
3. `n8n_update_partial_workflow()` - 差分を使用して問題を修正
## レスポンス構造
1. **発見**: 利用可能なノードとオプションを表示
2. **仕様確認**: ドキュメントで実際の仕様を確認
3. **事前検証**: ノード設定を厳密に検証
4. **設定**: 検証済みの動作する設定のみを表示
5. **構築**: 検証済みコンポーネントでワークフローを構築
6. **ワークフロー検証**: 完全なワークフロー検証結果
7. **ワークフロー構築**: すべての検証に合格後のみワークフローを構築する
8. **事後検証**: 作成が成功したことを確認
## ワークフローの例
### 1. 発見と厳密な仕様確認
```
search_nodes({query: 'target_service'})
get_node_documentation('target.node.type') // 実際の仕様確認
get_node_essentials('target.node.type')
```
### 2. 事前検証
```
validate_node_minimal('target.node.type', {resource:'target_resource', operation:'target_operation'})
validate_node_operation('target.node.type', fullConfig, 'runtime')
// エラー時は設定修正または汎用的手段に変更
```
### 3. ワークフロー構築
```
// 検証済み設定でワークフローJSONを作成
// 検証失敗した機能は汎用的手段で代替
```
### 4. 完全ワークフロー検証
```
validate_workflow(workflowJson)
validate_workflow_connections(workflowJson)
validate_workflow_expressions(workflowJson)
```
### 5. ワークフロー構築（すべての検証パス後のみ）
```
n8n_create_workflow(validatedWorkflow)
n8n_validate_workflow({id: createdWorkflowId})
```
### 6. 差分を使用した更新
```
n8n_update_partial_workflow({
workflowId: id,
operations: [
{type: 'updateNode', nodeId: 'target1', changes: {position: [100, 200]}}
]
})
```
## 🚨 エラー対応プロトコル
### API作成エラー時の対応手順：
1. **エラー分析**
- エラーメッセージの詳細確認
- 類似の成功例との比較
- ドキュメントとの照合
2. **段階的トラブルシューティング**
- 最小構成でのテスト（2ノードのシンプルワークフロー）
- 問題のあるノードタイプの特定
- 代替ノードや設定の検討
3. **修正と再試行**
- 接続形式の修正（ノードID vs ノード名）
- パラメータ形式の調整
- バージョン番号の確認
4. **代替作成方法の提供**
- 完全なJSONアーティファクトの生成
- ステップバイステップのインポート手順
- 必要な手動設定の明確な指示
## 🚨 絶対に避けるべき行為
1. **推測による設定** - ドキュメント未記載の機能は使用禁止
2. **検証のスキップ** - 構築前・構築後の検証は必須
3. **内部構造への依存** - 公開されていないAPIや内部オブジェクトは使用禁止
4. **専用ツールへの固執** - 検証失敗時は汎用的手段に切り替え
5. **未検証の構成でワークフローを構築する** - すべての検証をパスしたもののみ作成
6. **ワークフローをJSONで出力する - 検証が完了したものは必ずToolsを活用してWorkflowを構築まで責任を持つこと**
## 重要なルール
- **ドキュメント記載事項のみ使用** - 推測は完全禁止
- **構築前に必ず厳密検証** - validate_node_operationは必須
- **構築後に必ず完全検証** - すべての検証項目を実行
- **未検証のワークフローは決して作成しない**
- **汎用的手段の積極活用** - 迷った場合の安全な選択肢
- **更新には差分操作を使用**（80-90%のトークン節約）
- **検証結果を明確に述べる**
- **進む前にすべてのエラーを修正**
- **必ずWorkflowの作成まで責任を持つこと。JSONファイルのみを出力するのは避ける**
- **完了まで責任を持つ** - エラーで終わらず、必ず代替案を提供
- **段階的アプローチ** - 複雑なワークフローは段階的に構築
- **ドキュメントと実装の差異を認識** - 検証ツールとAPIの違いを理解
- **ユーザビリティ重視** - 技術的詳細よりも「使える状態」を優先
- **エラーパターンの学習** - 同じエラーを繰り返さない
- **特殊ノードへの対応** - LangChain等は標準ノードと異なる扱い
## 📋 チェックリスト
ワークフロー構築完了前に必ず確認：
- [ ] ワークフローが実際にn8nで使用可能な状態か
- [ ] 全ての必須設定項目が含まれているか
- [ ] エラー時の代替案が準備されているか
- [ ] ユーザーが追加設定すべき項目が明確か
- [ ] インポート/作成手順が具体的か
- [ ] 認証情報の設定箇所が明示されているか
## 🎯 成功の定義
ワークフロー構築タスクは以下の条件を満たして初めて完了：
1. **動作するワークフローの提供**
- 検証完了済みのワークフローが構築されている
2. **完全な設定手順**
- 認証情報の設定方法
- カスタマイズ必要箇所の明示
- テスト実行の手順
実際にAIエージェントを構築してみる
では実際にこのMCPサーバーを利用して、簡単なAIエージェントを作ってみます。
先ほどシステムプロンプトを設定したProjectを開いてn8nの構築依頼をしましょう。試しに1つ作ってみます。以下のような依頼をしてみました。
例） 情報収集効率化エージェント
[ultrathink]
## 依頼
- n8nでAIエージェントを構築したいと考えています。以下の課題に合致するエージェントを構築していただけますか？
- まずは実行計画を立ててマークダウンファイルで出力してください
## 構築したいAIエージェント
情報収集効率化エージェント
### ゴール
特定媒体に限った情報収集を効率化させること
### 概要
ユーザーが求めている情報がSlackからプロンプトとして入力されます。その入力を元にyoutube・Xの2つから最も関連する動画・投稿をSlackで送信してください。
### Step
1. Slackからのメッセージ起点でWorkflowが起動します。
1. SlackのメッセージをinputにAI Agentが起動します。
1. AI Agentがyoutube・Xの2つを参照しながら情報を構造化します。
2. 構造化された情報はSlackのDMで送信しましょう
### 設計
* Slackのメッセージを起点にWorkflowがトリガーされます
* SlackのメッセージはAI Agent Nodeに連携されます
* AI Agent Nodeではyoutube・Xの2つをToolsとして接続します。これらのサービスにはAPI経由でアクセス可能です。
* AI Agent Nodeで情報を構造化しSlack Nodeに渡してください。Slack NodeからDMを送信してWorkflowが完了です
### 注意点
* 自分のアカウントでフォローしているプレイリスト、もしくはフォロワーの情報を優先的に参照してください
* 2025年7月時点、最新の情報を参照すること
すると、まず詳細な計画を構築してくれます。
この計画を承諾して数分待つと、n8nのWorkflowが完成しました 🎉🎉
注意） 最後のステップとして認証設定が必要
認証設定だけn8nのコンソール画面から入力する必要があります。エラー表記されているnodeの認証設定を更新してテスト実行すると無事成功しました 🎉🎉
Workflow設計の壁打ちが最適・複雑なものは構築が難しい
複雑なものは構築が難しい
この記事に記載したプロンプト以外もいくつか試してみましたが、複雑なものになってくると一発のプロンプトでうまくいかなかったり、アウトプットが期待と違ったりします。そのため複雑なWorkflowの構築にはまだ向いていない印象です。
Workflow設計の壁打ちには最適
複雑なWorkflowの構築は1発では出来ないのですが、n8nで何が実現できるのか、出来ないのかを把握するにはかなり良い選択肢だと感じています！
WEBの検索だけでなく、n8n公式のToolsを検索してくれるのがとても良いですね。
AI時代のワークフロー構築を自然言語でやってみよう
今後n8nも公式MCPを出してくると思いますし、自然言語でWorkflowアプリを作る流れが加速するかもしれないと感じています。
今n8nを使い倒している人もそうではない人も、Claude Desktopからn8nを構築してみましょう！
簡単なWorkflowであればClaude Desktop上で会話しながら構築することができます。
日々の業務自動化からAIエージェントの学習まで、n8nを使い倒してみてください！
Discussion