RAKSUL TechBlog

RAKSULグループのエンジニアが技術トピックを発信するブログです

n8n-mcp & n8n-skillsで始めるn8nワークフロー生成

はじめに

ノバセルで PdM をしていた山中です。現在は親会社のラクスルへ出向しており、全社の AI 活用推進を担当しています。ノバセルとラクスルの双方で n8n の社内ホスティング環境が整い、自動化や AI 化は日増しに加速しています。

一方で、n8n の柔軟性はエンジニアリング知識を前提にした設計で支えられています。だからこそ非エンジニアには最初の一歩が重く、導入のハードルが高く映ります。私も非エンジニアメンバーに伴走してワークフロー構築を支援していますが、初期構築の壁を越えるには学習コストがかかり、人力だけで支援体制をスケールさせるのは限界があると感じてきました。

では、n8nのワークフローをGeminiやChatGPTに作らせてみると、出来上がるのはノード間が繋がっていないものや、古いバージョンのノードを利用したものなど・・・。精度に問題がありました。 そこで今回は、n8n-mcp と n8n-skills を組み合わせてワークフロー生成をどこまで自動化できるのかを検証してみます。

n8n-mcp / n8n-skills の概要

n8n-mcp は、n8n の 500 以上のノード定義・プロパティ・テンプレートを丸ごと AI から参照できるようにする MCP (Model Context Protocol) サーバーです。Claude などのアシスタントが search_nodesget_nodevalidate_workflow といった MCP ツール経由でノード仕様を照会したり、n8n API を経由してワークフローの作成・更新・実行まで行えます。npx や Docker などでサクッと立ち上げられ、ドキュメント/テンプレート検索、構成バリデーション、ワークフロー差分更新といった “AI による n8n 操作” の下支えをしてくれる存在です。

対になる n8n-skills は、n8n-mcp を正しく使いこなすための Claude Code スキル集です。n8n の式記法、MCP ツールの使い分け、代表的なワークフローパターン、バリデーションエラーの読み解き方、ノードごとの依存関係、さらに JavaScript/Python のコードノードでの定石まで 7 つのスキルとして整理されています。これらを読み込ませることで、AI は n8n-mcp が提供する豊富なデータベースを文脈に応じて呼び出し、現実的なワークフロー設計や自動修正まで一貫して行えるようになります。

二つのツールを組み合わせれば、AI が構築プランニングから実装・実行・デバッグまでを一気通貫で担えるようになります。

今回試すワークフロー

今回は、Slack でボットに声をかけるだけで複数人の Google カレンダーを横断検索し、最適な空き時間を提案・予約まで担ってくれる AI アシスタントを題材にします。面倒なカレンダー確認や候補書き出し、最終的な予定登録をすべて n8n に任せ、ユーザーは Slack 上の自然言語対話だけで調整が完結するイメージです。

利用する主要ツール

  • Slack:ユーザーとのインターフェース(問い合わせと結果通知の両方)
  • Google Gemini:自然言語から参加者や希望日時を抽出する LLM
  • Google Calendar:参加者ごとの予定取得と確定イベントの登録先

2 段階の処理フロー

ワークフロー全体は「空き時間の提案」と「日程の確定」という二つのステップに分けて設計します。

  1. 空き時間の提案
    ユーザーが Slack で「@Bot A さんと B さんの日程調整をお願い」とメンションすると、まず Gemini がメッセージから関係者や制約条件を抽出します。その後、関係者全員の Google カレンダーを取得し、辞退済みの予定や重複を除外しながら空き時間を算出します。計算結果は候補リストとして Slack に返し、ユーザーが選べる状態にします。
  2. 日程の確定
    ユーザーが「12/1 の 10:00 でお願いします」と返信すると、再び Gemini が日時情報を読み取り、本当に全員のカレンダーが空いているかを再確認します。問題がなければ Google Calendar にイベントを自動登録し、完了通知を Slack に返して調整フローを締めます。

この 2 ステップを n8n-mcp と n8n-skills を活用しながら自動生成させ、どこまで実用的なフローに近づけるかを追っていきます。

n8n-mcp 単体で試したケース

まずは n8n-mcp だけを有効化した状態で今回のワークフローを生成してみました。入力したプロンプトは次のとおりです。

このワークフローは、**Slackで日程調整を自動化するAIエージェント**です。ユーザーがSlackでボットにメンションすると、対象者のGoogleカレンダーを確認し、空き時間を提案してくれます。
---
## 主な機能フロー

Slack → AI解析 → Googleカレンダー確認 → 空き時間計算 → Slack返信

## 処理の流れ
**1. トリガー(Webhook)**
- Slackの app_mention イベントを受信
- ボットからのメッセージや削除イベントはフィルタで除外
**2. リクエスト種別の判定**
- **新規リクエスト**(スレッド返信でない場合)→ 候補日程の提示フローへ
- **スレッド返信**(日程確定の返信)→ 日程確定フローへ
---
## 候補日程の提示フロー(新規リクエスト時)
1. **一次回答**: Slackに「リクエストを受け付けました」と即座に返信
2. **AI情報抽出**: Google Geminiで、メッセージから日程調整対象者(例: y.yamanaka)を抽出
3. **Googleカレンダー取得**: 各対象者のカレンダーから予定を取得
4. **予定のフィルタリング**:
   - 「予定なし」設定の予定を除外
   - 欠席(declined)した予定を除外
5. **空き時間計算**: JavaScriptで予定をマージし、空き時間スロットを算出
6. **メッセージ作成**: 日付ごとの空き時間リストを整形
7. **Slack返信**: 候補日程をスレッドに投稿
---
## 日程確定フロー(スレッド返信時)
1. **AI Agent**: ユーザーの返信から確定日時を抽出(例:「12/01 09:00〜10:00で!」)
2. **履歴取得**: スレッドの過去のやり取りを取得
3. **対象者抽出**: 過去メッセージから日程調整対象者を再度抽出
4. **空き確認**: 確定希望日時が本当に空いているか各カレンダーをチェック
5. **結果分岐**:
   - **空いている** → Googleカレンダーに予定を作成し、Slackで確定通知
   - **埋まっている** → 「日程が埋まってしまった」旨をSlackで通知
---
## 使用している主な連携サービス
| サービス | 用途 |
|---------|------|
| **Slack** | トリガー受信、メッセージ送信 |
| **Google Calendar** | 予定取得、予定作成 |
| **Google Gemini** | 自然言語からの情報抽出(対象者、日時) |
---
## 特徴
- **AIによる自然言語理解**: 「y.yamanakaとy.isobeの日程調整をして」のような自然な日本語を解析
- **複数人対応**: 複数の対象者のカレンダーを統合して空き時間を計算
- **日本時間(JST)対応**: タイムゾーンを考慮した日時処理
- **会話形式**: 最初に候補を提示 → ユーザーが選択 → 自動で予定作成という対話型フロー

生成されたワークフローは概ねプロンプトを反映していましたが、次の 2 点で期待と乖離しました。

n8n-mcp単体で作成したワークフロー

  1. AI ノードが組み込まれておらず、自然言語の解釈を別途用意しなければならない構成になった
  2. 候補日程の提示フローしか出力されず、確定フローが生成されなかった

結果として “シンプルな雛形” に留まり、このまま運用に載せるには大幅な加筆が必要という印象でした。

n8n-mcp × n8n-skills で試したケース

次に n8n-skills も読み込んだ状態で同じプロンプトを投げ、構成の差を確認しました。

n8n-skillsを組み込んで作成したワークフロー

こちらでは AI Agent ノードが適切に挿入され、候補抽出と日程確定の双方をつなぐフローが生成されました。Slack の会話コンテキストを保持したまま候補を出し分ける構造など、実際の業務で使えるレベルに一気に近づいた感触です。

一方で、Slack の「スレッド履歴を取得するノード」が誤ってメッセージ送信設定になっていたり、タイムゾーンの考慮漏れで候補日時が正しく算出できないなど、細かなバグは残りました。ただし、これらは n8n-mcp のノード検索で適切なノードを引き直したり、実行履歴を確認して原因を突き止めることで解消できました。スキル導入で “ある程度完成形に近いワークフロー” が得られ、残りはバグ修正やパラメータのチューニングに集中できる、という分業イメージです。

n8n-mcpを利用してノードを修正する様子

まとめ

n8n-skills はベースラインとして十分に整ったスキルセットであり、n8n-mcp と組み合わせることで実用的なワークフローを短時間で組み上げられることが確認できました。デバッグまで含めた一連の作業を AI に任せる道筋も見えてきたため、今後の n8n 実装でも積極的に使っていきたいと感じています。

一方で、実運用に耐えるには自分たちでスキルや手順を微調整する必要も見えてきました。

  • スキルを参照せずに n8n-mcp を直接呼び出してしまい、精度が落ちる
  • n8n のバージョン差によるパラメータ違いを吸収できない
  • 一部ノードはドキュメント上に具体的なパラメータ形式がなく、AI が迷いやすい

こうした特性を押さえておくと、AI に任せる領域と人力で補う領域を切り分けつつ、高い再現性で n8n ワークフローを量産できそうです。