💨

【ノーコードツール】n8nで1ヶ月開発して地獄を見た話

に公開
ノーコード
ローコード
n8n
Vibe Coding
tech

みなさん、ノーコードツールを使った経験はあるでしょうか？
何かとエンジニアに嫌われがちなノーコードというワード。確かにコードを書ける人間からすると使う必要のないツールだと思いますよね。
ノーコードツール自体は昔から存在していますが、ここ数年はChatGPT,Gemini,ClaudeなどのAIの能力が飛躍的に向上しているのもあり、ノーコードツールにこれらを取り入れることで、場合によっては簡単に人間並の作業をしてくれるワークフローを構築できるようになってきていると思います。

実は最近1ヶ月ほど非エンジニア(プログラミング等は全くの未経験)の人間とノーコードツールを使って開発をするという珍しい機会がありました。その中で、タイトルにもある通り大変な思いをしたので、私の1ヶ月の苦悩を雑にまとめてみました。

作ったワークフローは、ざっくり言うとPDF等の書類をOCRで読み取ってそのテキストデータをChatGPTに読み取らせてその結果を保存するという、概要だけだと簡単にできそうなものです。しかし、やりたいことを実現するためには地味に多くの分岐やデータの整形が必要でした。そして、n8nで複雑な処理を実装しようとした、、、この時点で詰んでいたことを後から知ることになります。ちなみに構築したワークフローの全体像の半分くらいをスクショしたのが以下の画像です。なんじゃこりゃ。

※以下、ワークフローを構築しながら書いた愚痴の箇条書きがひたすら続きます。

苦労したこと

バイブコーディングできない

  • AIに「前のノードからこんな入力がくるからこういう形式で出力するjsのコード書いて」みたいなノード単位での指示の出し方はできるけど、これを繰り返さないといけないから実装にすごく時間がかかる。
  • n8n自体を使いこなさないといけないので、エンジニアも大して非エンジニアと作業スピード変わらない(どんな種類のノードがあるとかわからん)。

ChatGPTやGeminiがあてにならない

  • 仕様がわからなくてChatGPTやGeminiに相談しても平気で嘘を言う(ネットに情報が少ない？)ので、自分で試行錯誤する間に時間が溶ける。

とにかく重い

  • 1つの実行ログを開くまでに5,6秒程度かかる上に、大きめのデータ(それでもせいぜい10MBとか)のやり取りをしているワークフローの実行ログを見ているとページがクラッシュしたりする。
  • 複雑なワークフローで作業してると信じられないくらいページが重くなる。
  • ワークフローが複雑になってくるとお話にならないくらい重くなるのでワークフローを複数ページに分割する必要が生まれる(今回は3つに分けた)。
  • メモリ4GB以上食ってた時もあった(分割後の話です)。
  • メモリ不足でChromeが停止することもしばしば。

ノーコードツールではなくもはやコードノードツール

  • エンジニア以外も見やすくなるように機能単位でコードノードを区切った結果、コードノードまみれになって全然ノーコードツールじゃなくなった。
  • 入力データの形式が決まってたりするとそれに合わせてデータを整形したり、データの内容によっては処理を分岐させる必要があるので、どうしてもコードでデータを整形する必要が生まれる。そうなるとコードノードが多くなる。もはやコードノードツール。

コードノードでできることが限定的

  • コードノードでパッケージをimportして使うことが(基本的に)できない。
  • ローカル環境での開発ならn8nをDocker上で動かすならできることは多くなるが、今回のようにn8n cloudだとそれはできない。
  • どうしても使いたいサービスはマイクロサービスとして外部に切り離してそれをn8nから呼び出す必要がある(めちゃ不便)。

可読性が低い

  • 複雑になってくると、他人が見た時にどういうワークフローなのか1つ1つノードをクリックしていかないとわからない。
  • ノードに名前つけるのサボったりするとデフォルトの名前(JavaScript 8とか)だらけになってしまうので自分でもよくわからなくなる。
  • ノード同士を繋げる矢印の場所をユーザーがコントロールできないので複雑なワークフローだと他者が見た時に何が何だかわからなくなる。
  • だからこそ数ヶ月後に久々に見たら自分でも訳わからなくなってそうで怖い。

実行ログが扱いづらい

  • 先述した通りログを開けるまでが遅すぎる。
  • ログを開いても、ぱっと見でどのノードが実行されてどの分岐の処理が走っているのかがわかりにくい
  • 個々のノードをクリックしないと入出力がわからない。
  • ノードの入出力を一度に見る時にモニターがないと画面の横幅が全く足りん。

テストが大変

  • ノードごとにテストできる機能がないため、挙動をテストしたいときは(1)期待する入力データを渡してくれるノードを用意、(2)そのノードとテストしたいノードを繋ぐ、(3)もともと繋いであったノードの接続を一度切る、という手順を踏まないとテストできない。
  • しかもそれを各ノードごとに用意するとグチャグチャなワークフローになる。
  • しかもそれらを一括でテストするようなことはできず、個々のノードをぽちぽちしないとテストできない。
  • そのノードにいろんな入力パターンを試したかったら、パターンの数だけノードを用意する必要がある。

意外とできないことが多い

  • SlackやGmailノードで特定の処理ができなかったりして、最終的にHTTP Requestノードに頼ることもしばしば。

独自の仕様に慣れるのが大変

  • 入力データを取り出す形式が独特で、欲しいデータを簡単に取り出せなかったりする。
  • しかもその仕様に慣れてもツールを乗り換えることになるとその知見がリセットされる。

得られたもの

愚痴だけで終わってもアレなので、得られたものも少し書いておきます。

Chrome拡張のClaude Codeの便利さに気づけた

  • Chrome拡張のClaude Codeのおかげでcontextを入力する手間が減って楽になった(n8nのコードノードを作ってて、こういう入力が来るので〜みたいなことを言わなくて良くなった。n8nでコード書いてる前提で、n8n仕様の特殊な入出力形式でちゃんと書いてくれる。)

プロンプト最適化の練習

  • GPTに読み取らせる箇所が何箇所かあり、プロンプトの修正をひたすらしまくったので、「こう言う指示はあえてざっくり書いた方がGPTが気を利かせて読み取ってくれる。ルールで縛りすぎると逆にノイズになる。」みたいな細かい発見もあり、プロンプトエンジニアリング的な目線だといい練習になった(モデル変わったらリセットされるかもしれないけど)。

振り返り

最後に少しポジティブなことも書きましたが、この1ヶ月はかなり大変な思いをしたので、やはりコードが書ける人はコードを書くべきだなとつくづく思いました。あと書いてて思ったけどコードバリバリ書いてるから全然ノーコードじゃないですね。
コードを書きたくなくてシンプルな(データの整形とか必要ない)ワークフローを組みたい人に向いているツールかなと個人的には思います！

Discussion