先週の火曜日の夜11時、Claude Code が本番のeコマースストアから140件の製品バリエーションを削除するのを見てしまいました。悪意はありませんでした。技術的にも間違っていたわけではありませんでした。
私が直してほしいと依頼したワークフローは、4つのフィールドだけを含むPUTリクエストをPrestaShopのXML APIへ送るものでした。PrestaShop はそれを「他のすべてを空に設定する」と解釈しました。参照情報は消え、バーコードも消えました。別の端末タブで実行ログを比較している間に、140の組み合わせが黙って消されました。
TL;DR: n8nは死なない。手動のワークフロー構築は死にかけている。 czlonkowski/n8n-mcp というオープンソースリポジトリが Claude Code を n8n のアーキテクトに変えた。実際の55ノード規模の本番パイプラインでこれを使い、別個に自分のAIエージェントを停止した。以下には、実際に機能するもの、壊れるもの、そしてどのツールをどの場面で使うべきかのフレームワークを示す。
あなたのロゴがAIエージェントより信頼できるとき。
15分後、Claude Code は根本原因を特定し、修正を作成しました（4つの新しいノードを横断する GET-before-PUT パターン）、12件の変更を単一の原子API呼び出しでデプロイし、修復をPrestaShop API の前後の状態を取得して検証しました。
同じ調査を n8n の UI で行えば1時間以上かかったでしょう。以前それを経験したことがあるので分かっています。55ノードをクリックし、ブラウザのタブを切り替え、JSON を手動でエクスポートし、実行データを目視で確認します。
2週間前、私自身の AI エージェントを無効化しました。数か月にわたって構築・執筆してきた多モデルシステム OpenClaw のプラグを抜いたのです。費やしたトークンの価値に対する比率は負でした。エージェントは実作業をする代わりに自分自身を更新するための計算資源を使い続けました。
だから今、端末には矛盾がありました。自分で作ったAIエージェントは自分の電気代を正当化できず、AI支援のワークフローシステムは本番データベースを15分で救ってしまう。
その矛盾は、現在の n8n 論争のほぼ全てと言えるでしょう。
n8n の職務内容を変えたリポジトリ
3 か月前、Claude Code に私のための n8n ワークフローを作ってくれと頼みました。
それは scheduleTrigger というノードを作りました。そのノードは存在しません。本物は schedule と呼ばれます。JSON ファイルのインポートエラーを 20 分かけてデバッグしました。JSON の各プロパティ名はほぼ正しかったのに import には十分でなく、壊れてしまいました。Claude もそれについては自信満々でした。幻覚のピークエネルギー。「Here's your workflow」と言われ、JSON は美しく見えますが、ノードタイプの半分がファンフィクションだと分かるまで。
その後、 Claude Code に n8n を触らせるのをやめました。
czlonkowski という開発者がオープンソースの MCP サーバを公開しました。そして次に Claude Code にワークフローを作ってくれと依頼したとき、それはすべてのノード名、すべてのプロパティスキーマ、すべての IF ブランチの接続構文を知っていました。幻覚はなし。推測もなし。
その後のオンライン議論は次のように進みます。Claude Code が n8n の市場を奪っている。Google Trends は検索関心で n8n を追い越すことを示している。n8n のチュートリアルで視聴者を築いた YouTube クリエイターは視聴回数が落ちていく。「Is n8n Dead?」というフォーラムのスレッドが2 週間おきに現れる。結論はいつも同じ、異なるスキルレベルには補完的なツールだ、という温い見解です。
その結論は正確でありながら、全く役に立ちません。
実際の変化はもっと具体的です。czlonkowski の n8n-mcp サーバ（GitHub 上）は Claude Code に対して、1,084 個の n8n ノード、テンプレートから抽出された2,600件以上の実世界の設定、デプロイ前にミスを検出する検証ルールへの組織的なアクセスを提供します。併設のプロジェクトは、式の構文、アーキテクチャパターン、デバッグを網羅する7つの Claude Code スキルを追加します。
n8n も公式 MCP を提供しました（Settings > Instance-level MCP）。しかし彼らのものは意図的に制限が多く、既存のワークフローをトリガーしてクエリするのみで、新規の作成はできません。セキュリティを重視した選択であり、弱点ではありません。
結局起きたのは、n8n のビジュアルビルダーが死んだのではなく、役割が変わったことです。かつては構築ツールでした。今は監視ダッシュボードです。Claude Code が構築を担い、n8n が実行します。
ただし、ワークフローをより速く構築することは、それだけではありません。私の n8n インスタンスでは15個のワークフローが動作しています。先月、3か月触っていなかったものを開いたところ、中間の20ノードが何をしているのか全く分かりませんでした。1回の MCP 呼び出しで Claude Code は各ノードに「これが何をするのか」「何を期待するのか」「変更すると何が壊れるのか」という付箋を貼りました。その付箋だけでもセットアップの価値がありました。しかし、それを変更ごとに繰り返せると気づきました。
ワークフローを編集するものは変更を文書化し、実際に何が起こったかを説明するメッセージとともに git にコミットします。私の3つのデバッグセッション全体で、それは完全なロールバック機能を備えた30件のコミット、マニュアルなエクスポート/インポートのクリックゼロを意味しました。n8n の UI でそれをやろうとしても無理です。
ご注意: このセットアップは、あなたの n8n インスタンスに対して読み取り/書き込み権限を持つ AI に API トークンを渡すことを意味します。私はステージングと本番環境の両方でこれを行っています。これはリスクフリーだとは言いません。私のワークフローの1つでは、Parametersノードの中に平文のまま PrestaShop APIキーが見える状態で Claude Code がそれを確認できました。直接 curl 検証には有用ですが、資格情報の健全性にはとても悪影響です。セキュリティ専門家がこの話を読んだら、フォースの乱れを感じるでしょう。すみません。MCPレイヤーには現在、資格情報のスコープ機能はゼロです。
私は先月、CLIがほとんどのAIエージェントツールよりMCP を上回ると主張しました。汎用エージェントに関してはまだそれが真実だと思います。しかし、n8n のような特定でよく文書化されたプラットフォームではどうでしょうか。構造化された MCP アプローチが勝ちます。czlonkowski がそれを証明しました。
実際の本番デバッグからの3つの瞬間
私は redactedshop.com のeコマースパイプラインを運用しています。ヨーロッパのアウトドア小売サイトで PrestaShop 8.2.1 を使用。サプライヤーが FTP 経由で CSV カタログを送信します。n8n のパイプラインは CSV を読み取り、Google Sheets にパースします（GeminiによるAI支援のバリアント検出を用いて）、その後 PrestaShop 内に約265商品を作成・更新します。価格、在庫、画像、カテゴリ、3言語の翻訳を含みます。2つのメインワークフロー、6つのサブワークフロー、合計55ノード。
3つのデバッグセッションにまたがる2週間で、Claude Code と n8n-MCP の組み合わせは、些細な問題から「どうやってこれが動いたのか」まで対処しました。3つの瞬間が特に際立ち、それぞれが異なる点を証明しました。
沈黙の消去
更新するバリアントの prix ノードは、/api/combinations/{id} へ id、id_product、minimal_quantity、price のみを送信する PUT を送っていました。PrestaShop の API は部分 PUT を「リソース全体を置換する」と見なします。うっ。送信しなかったフィールドはすべて空になります。これにより、140 件の製品バリエーションの参照コードと EAN バーコードが沈黙のうちに消去されました。別のノードも同じパターンで、executeOnce: true に設定されていたため、最初の製品のみ更新され、残りは完全にスキップされました。
Claude Code は MCP 経由で実行データを取得し、特定の組み合わせIDを抽出、PrestaShop API へ GET を実行して被害を確認、GET-before-PUT パターンを実装する新しい4つの Code ノードを作成、IF 分岐の4本の接続を再配線、executeOnce フラグを削除、合計12の変更を1回の n8n_update_partial_workflow 呼び出しでデプロイしました。n8n の UI では、そのシーケンスは次のようになります：ノードを作成して配置し、6つ以上の設定フィールドを埋め、接続ワイヤをドラッグして、4回繰り返し、最後に手動で検証。現実的には、慎重なクリックで約20分。1回の API 呼び出しで完了し、3分で検証されました。
それが高くついたバグでした。次のバグは安価で苛立たしいものでした。
存在しなかった型
Google Sheets は、セルに値がある場合は product_id: 32210（数値）を返しますが、値がない場合は product_id: ""（空文字）を返します。n8n の IF ノードの exists 演算子は、空文字が「存在する」ため、空文字を黙って通してしまいます。単に空です。
JavaScript の型強制が再び発動します。[] == false だが [] ? true : false は true を返します。Google Sheets はそれをさらに悪化させました。
このセッションを通じて機能するフィルターへ収束させるべく4回のコミットを行いました。最初は exists が失敗、次に isNotEmpty が数字で詰まり、最後に gt 0 の typeValidation: loose が機能しました。
この MCP 実行インスペクターはこれを診断可能にしました。各ノードから出力される正確なデータ構造を示し、それがすぐに混在型の問題を露呈しました。実行データへのプログラム的アクセスがなければ、n8n の UI 実行インスペクターをノードごとにクリックして JSON 出力パネルを睨みつつ進めるしかなかったでしょう。それでも、IF ノードの最初の3回の試みはすべて間違っていました。Google Sheets の混在型の挙動はどこにも文書化されていません。経験的に発見するしかありませんでした。フィルターを直すのに4回のコミット。これが本当のペースです。
その2つのバグにはきれいな結末がありました。3番目だけはそうではありませんでした。
実現されなかったテスト
バリアント更新パスを修正した後、単純な製品更新パスも検証する必要がありました。問題: 現在の Google Sheet のデータセットには単純な製品が存在しませんでした。Claude Code の解決策は実用的でした：Code ノードの JavaScript を node -e でローカルに実行し、既知の製品へ curl で手動 PUT を行い XML 変換が全フィールドを保持していることを検証します。
これは正規表現とXMLのロジックを検証します。n8n の式参照、ノード連結、continueOnFail の挙動は検証しません。修正は部分的に未検証のまま本番環境へ適用されました。私はそれを知っています。Claude Code も指摘しました。完全なエンドツーエンドのテストには Google Sheet に単純な製品行を挿入する必要がありますが、まだそれを実施していません。
これを伝える理由は、Claude Code + n8n に関する他の記事のほとんどがハッピーパスを示しているからです。現実の道には、適切な統合テストなしに公開された修正と、最初の実行でクラッシュした Code ノードが含まれています。Claude Code が自分のスキルドキュメント（配列で包んだリターンが推奨されている）に従ったのに対し、n8n の runOnceForEachItem モードの実行時バリデータは配列を拒否します。
部屋で最も賢いツールでさえ、ルールを学ぶには失敗した実行を必要とします。
なぜ自分のAIエージェントを無効化したのか
最後のセクションは、組み合わせに否定的だと受け取られるかもしれません。そうではありません。デモがすべてハッピーパスで終わり、初回実行でクラッシュした Code ノードを誰も示さないバージョンに対して否定的です。デモと本番の間のギャップをさらに進めると、それがまさに私のエージェントを破滅させた原因です。
私は OpenClaw を作りました。5ドルの VPS 上で動作するマルチモデルAIエージェントです。主要モデルとして Kimi K2.5、フォールバックとして MiniMax M2.5。オリジナルのバージョンは Claude の OAuth で動いていましたが、Anthropic がそれを終了させ、全員に有料 APIキーを課すよう強制しました。これが「安価な実験」から「実際の予算決定」への経済的転換点でした。
Peter Steinberger は frontier モデルを使うか、何も使わないべきだと主張しました。技術的には彼が正しい可能性が高く、OpenClaw の多くの問題は、自己更新と自己修復が信頼できるほど賢くないモデルに起因していました。 frontier モデルはそれを解決する可能性が高い。しかしこの発言の直後に Steinberger は OpenAI に参加し、 frontier API 価格は無監督エージェント向けで1日あたり200ドルに達することがあります。現実の予算で実 workloads を動かしている私たちにとって、正しいことがすぐに手頃になるわけではありません。
私は安いモデルで何ヶ月も OpenClaw を展開しました。その後それを停止しました。API コストで同じ壁にぶつかり続ける Roomba のプラグを抜くようなものです。
比率は正直で容赦ありませんでした：消費したトークンを生み出された価値で割った値はマイナスでした。エージェントは自己更新やツールの修正、失敗したプロセスの再起動を試みるため、計算資源を頻繁に消費し続けました。修正はあります。より賢いモデルです。しかし価格は違います。その領域が本当に必要としているのは、 frontier 級のトークンを消費せず機能するインテリジェントな CRON システムと実際の自己ツール機能です。自分でそれを作ろうと考えていますが、それは別の記事です。
一方、私の n8n ワークフローは何ヶ月も動作しています。ウェブフックは発火し、CRON は実行され、製品が更新され、在庫が同期され、通知が送信されます。介入ゼロ。初期構築を超えるトークン費用ゼロ。実行ログは監査可能で、エラーハンドリングは決定論的、ホスティングは安定しています。
ビジネス自動化の80%は退屈で、 "AIエージェントがすべてを置換する" 派の誰もそれを聞きたくありません。6時に発火するCRONジョブ、Stripeイベントを捕捉するウェブフック、IF/ELSEの分岐でデータを正しいエンドポイントへルーティング。これについて“推論する”エージェントは必要ありません。信頼して実行でき、運用コストがかからないパイプラインが必要です。
n8n はそれを実現します。
Claude Code + MCP は構築を劇的に速くします。実際、“劇的に”を数値で示しましょう。私が午後を費やすことになっていた PrestaShop のデバッグは15分で完了しました。私のスタックは Claude Max のサブスクリプションと、5ドルの VPS 上の自分でホストした n8n インスタンスで動いています。安くはありませんが、24/7 動作の無監督エージェント向け frontier API 料金と比較すれば端数です。そしてこの組み合わせは、人々が自律エージェントに求める用途の90%をカバーします。
エージェントは無駄ではありません。むしろ希少です。本当に動的な推論が必要なとき、それはエージェントの領域です。それ以外は追加ステップを伴うワークフローで、費用が嵩みます。
私はエージェントを作り、記事を書き、プラグを抜いた。
フレームワーク: 何をいつ使うべきか
実運用で両方を動かし、片方を停止させた経験から、こんなふうに判断します。
n8n だけ であなたが思う以上のことを扱えます。安定して反復的なプロセス。ウェブフック、スケジュールCRON、2つのAPI間のデータ同期、通知パイプライン。非技術者が何が動いているかを理解する必要があるとき。監査証跡と実行ログが必要なとき。可用性が柔軟性よりも重要なとき。私の5つのSaaS製品は、automationの約80%を n8n のみで実現しています。
Claude Code だけ は、繰り返しが起きない場合に適したツールです。データセットを変換するクイックスクリプト。来週には捨てるプロトタイプ。n8n に組み込むには過剰設計になるほど特化したカスタムロジック。探究モード、展開モードではありません。
さて、ここからが面白い部分です。頭の中でマッピングしているワークフローのノードを n8n の UI で45分もドラッグするつもりなら止めてください。それは Claude Code + n8n via MCP の領域です。外部 API の状態と実行データを照合する必要がある複雑なパイプラインのデバッグ。既存のワークフローの移行やリファクタリング。数か月触っていない dozen のワークフローを自動で文書化。そして、ますます、Airtable や Google Sheets をただのインターフェースのふりをさせてバックエンドとして n8n を使う実アプリを構築する動き。まだこの方法で完全なフロントエンドを出荷していませんが、アーキテクチャは明らかです：Claude Code が n8n のウェブフックと対話する本格的なUIを作ります。適切なバックエンドを備えた適切なアプリ。それが次に私が取り組むことです。
そして自律的AIエージェントの話です。IF/ELSE に還元できない推論が本当に必要なタスクのときに適切な選択です。入力が予測不能で、事前に意思決定ツリーをマッピングできないとき。トークンのコストが出力の価値に見合うとき。私の5つのSaaS製品の経験では、これは自動化タスクの約10%をカバーします。残りの90%はエージェントの衣装を着たワークフローです。私は自分のエージェントを最も華やかな衣装に着せたつもりですが、それでも踊れませんでした。
同じ規律はここにも適用されます： AIを実行させる前に契約を定義する。 Claude Code のプロンプト契約であれ、n8n のワークフロー仕様であれ、パターンは同じです。前方の明確さ、実行はその後。
最後に。czlonkowski は新しい n8n のリリースごとに n8n-mcp を維持しています。オープンソース、MIT ライセンス、ペイウォールなし。この記事全体を可能にしたのは一人の人です。リポジトリにスターを付けてください。それが私たちが彼に返せる最低限のことです。
Claude はついに n8n のノードは創作的なライティングのプロンプトだけではないことを学んだ。
リポジトリ: https://github.com/czlonkowski/n8n-mcp
もしこれがすでに動作しているものを再構築するのを防いだり、不要なエージェントへの投資を回避させるのに役立ったなら、私は週に1本こうした記事を書いています。ワークフロー自動化、実運用の Claude Code、チュートリアルが終わると壊れるもの。もし役に立つなら購読してください。
そのカバー画像？AIが作成しました。2017年には CSS のグラデーションで創造性を追求しましたが、それ以来私の芸術的キャリアは管理された衰退を続けています。
