n8nって便利なのかどうかわからない

ちょっと触ってみて、あまりにも苦戦したのでちょっと書いてみます。

簡単なもんだと思っていた

触ってみた感じ、多少でもプログラミングが分かっていないと手が出せない感じだと思う。なんか、見た目POPな感じだったから、ブロック繋げてできましたーって感じなんかと思っていたら、全然違った。多少複雑なことをできるほど、当たり前だが複雑になっていた。

結局、準プログラミング

私のようにClaudeCode全振りの人間にとっては、相性が悪いというか、もともと何もわかっていないので触りようがない。と言うのも、ClaudeCodeにワークフローを作ってもらったが、そのまま動くわけでもなく、修正が手作業。あと、情報が少ないのか、バージョンアップで変わっているのか分からないが、手作業で入れる前提になっているのか分からないが、そのままでは動く気配がないし、直す部分が多すぎる。直しても直しても動かない。

もちろん、ClaudeCodeでn8nをビルドしていく手法のノウハウが0なのでやり方が悪いのはもちろんあると思います。それにしてもややこしい。私のようにプログラミングなんて知りませんと言う方には正直結構難しいと思います。

そもそもが違う？

根本としては、n8nはノードを組み合わせてワークフローを簡単に作成できる。そして、流れが可視化され、運用も簡単。と言うのがポイント。また、ワークフローを共有できるので、多人数運用にも向いている。

私としては、私自分の為のものが出来れば十分で、別に他の人に共有したいわけでもないので無理して使う必要もない。やりたいことがノードの組み合わせで簡単に実現できるものでもない場合、無理してn8nに切り替える必要性が無かった。と言うか、夜の時間で二日頭ひねっても実装できなかったことが、ClaudeCodeとPythonだと1分で終わったのはあまりにも。もちろん、アクセストークンの準備などがn8nの方で準備していたからなのはあるが、それにしてもである。

もちろん、今回n8nでやりたかったのは定期実行が安定化して管理しやすいってのはある。Pythonだとその仕組みづくりがまた別に必要だが、
n8nはそれも含めたシステムなので管理まで含めると最終的にn8nの方が良さそうではある。

ただ、ノードの組み合わせで簡単にできることと、ノードを無理して組み合わせて実現することには大きな差があるように感じる。今回苦労したのは、簡単にできないことを実装していた部分に問題があったのは否めない。

まとめ

ここまで書いて思ったが、最初は難しいと書いていた。それは、いきなりややこしいことをさせようと思うからで、素人が初めて触ったExcelで変態マクロ（そこまでではないかもしれないが）を組もうとしていたから？それは言い過ぎか？

にしても、今回の問題は何でもClaudeCodeに投げる私とn8nの相性が悪かったのではと思う。おそらく、難しいことをさせなければ、定期実行、簡単管理のシステムが出来上がる。自由度が高いので、慣れるにつれて難しいこともできるでしょう。今回の敗因は、分からないし、相性悪いのに、いきなり難しいことをさせようとしたことでした。